En un esfuerzo por reducir el 'Tiempo de respuesta inicial del servidor' y así tener un mejor Google PageSpeed Insights, he estado tratando de optimizar el tiempo de respuesta de esa solicitud de 4.5Kb que toma alrededor de 270ms TTFB y 0.71ms descarga de contenido (medido usando herramientas de desarrollo).
La aplicación está alojada en un Linode en India que está físicamente cerca. Encendí los registros en Nginx porque sospechaba que algo andaba mal, pero muestra un tiempo de respuesta total de 25 ms.
Dado que Nginx define el tiempo de respuesta total como 'Tiempo de solicitud completo, comenzando cuando NGINX lee el primer byte del cliente y finalizando cuando NGINX envía el último byte del cuerpo de respuesta', esperaba que finalmente el usuario obtuviera la respuesta en un poco más de 25ms pero nunca 10x eso.
¿Alguna idea de lo que me podría estar perdiendo aquí? ¿Qué más puedo mirar?
ACTUALIZACIÓN: Tomé la decisión de migrar mi Linode a Singapur desde Mumbai y los resultados son mucho mejores ahora, pasé de 270 ms TTFB a ~ 100 ms. Lección aprendida, aunque la India está cerca, la alta velocidad de Internet de Singapur lo convierte en un lugar más adecuado para alojar mi aplicación.
De los documentos de registro de nginx
$request_time: tiempo de solicitud completo, que comienza cuando NGINX lee el primer byte del cliente y finaliza cuando NGINX envía el último byte del cuerpo de la respuesta.
...NGINX envía el último byte...
Lo que significa que ha enviado el último byte al sistema operativo subyacente. Entonces, los búferes de socket TCP podrían haber almacenado los bytes y están tratando de enviarlos al cliente.
Aquí hay un análisis de este escenario.
A Nginx no le importa el RTT (Tiempo de ida y vuelta) entre el cliente y el servidor. Eso es un problema del sistema operativo/cliente.
Hacer ping al servidor desde el cliente podría darle una idea del orden del tiempo de respuesta. Si el tiempo de ping es mayor que el $response_time de nginx, no se puede esperar que el rendimiento esté cerca de $request_time .
ping -c3 -s 1450 www.kernel.org PING ord.git.kernel.org (147.75.58.133) 1450(1478) bytes of data. 1458 bytes from ord1.git.kernel.org (147.75.58.133): icmp_seq=1 ttl=48 time=191 ms 1458 bytes from ord1.git.kernel.org (147.75.58.133): icmp_seq=2 ttl=48 time=192 ms 1458 bytes from ord1.git.kernel.org (147.75.58.133): icmp_seq=3 ttl=48 time=198 ms --- ord.git.kernel.org ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 191.155/194.026/198.468/3.205 msComo enfoque aproximado, si el tamaño de su respuesta es de 4,5 kB y el tamaño máximo del paquete TCP es de ~ 1,5 kB, puede esperar que el tiempo total sea, en el mejor de los casos, 3 veces el tiempo de ping.
En una caja de Linux, la unidad de transmisión máxima (MTU) es 1500:
ip addr | grep 'eth0: .*mtu' 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000La resolución de DNS podría tener una influencia.