¿Qué tan rápido debe tomar normalmente la solicitud / respuesta de red de un servidor a otro?

El tiempo que tarda una solicitud de un cliente en llegar a su centro de datos se rige principalmente por la física. Si su cliente está en Hong Kong y su balanceador de carga está en Albuquerque, Nuevo México, el tiempo de ida y vuelta será de 195.62 ms.

Entonces, en promedio, tomará ~ 100 ms para que cualquier paquete IP llegue a su centro de datos. Nota: Este no es el tiempo necesario para su solicitud, es el tiempo necesario para que algunos bytes arbitrarios lleguen a su servidor desde el cliente.

Con esto en mente, analicemos la solicitud / respuesta HTTP.

• Cómo obtener un pase de Microsoft Azure
• ¿Rackspace vs Amazon Cloud vs Google App Engine?
• ¿Cuáles son algunas consideraciones al planificar una migración de AWS?
• ¿Cómo limitar mis costos con el uso de la nube pública? ¿Hay alguna herramienta que pueda ayudar?
• ¿Debo usar AWS X-Ray para el monitoreo de aplicaciones AWS o una de las soluciones APM completas como Dynatrace, New Relic, AppDynamics?

1. Búsqueda de DNS del nombre de host
2. Establecer una conexión TCP al host
3. Enviar una solicitud HTTP a través de esta conexión
4. Espera una respuesta
5. Cierre la conexión (Opcional: HTTP 1.1 admite conexiones persistentes)

Fuente: Anatomía de una transacción HTTP

Las búsquedas de DNS implican consultar un servidor proporcionado por su ISP. El tiempo total para una búsqueda debe estar en el rango de micro segundos. Digamos – ~ 50 microsegundos .

Ahora volvamos a configurar la conexión TCP:

Fuente – Capa de transporte

Lo que esto significa es que tiene 1,5 viajes de ida y vuelta para configurar una conexión TCP, es decir, ~ 300 milisegundos . (TLS está más involucrado, no lo cubriré, pero si está interesado, la versión 1.2 del protocolo de seguridad de la capa de transporte (TLS) y la red de navegador de alto rendimiento)

Una vez que se establece la conexión TCP, debe enviar una solicitud HTTP al equilibrador de carga y luego recuperar una respuesta, que es otro viaje de ida y vuelta, por lo que ~ 200 milisegundos .

Por lo tanto, el tiempo necesario para una sola solicitud / respuesta HTTP 1 entre un cliente y su equilibrador de carga será de ~ 500.05 milisegundos .

Dentro de su red: su equilibrador de carga necesitará configurar una conexión TCP a su nodo y enviar la solicitud. Esto generalmente estará en el rango de microsegundos: ~ 50 microsegundos . Digamos que su servidor de aplicaciones lee algunos archivos localmente, realiza una consulta a la base de datos (a través de una conexión TCP ya establecida), etc. y prepara una respuesta. Obviamente, esto dependerá de su aplicación, pero voy a tirar una estimación de parque de pelota de ~ 1 milisegundo . Obviamente sabrás más sobre esto que yo.

El tiempo total para esta única solicitud / respuesta será de ~ 501.05 milisegundos . Luego, podría gastar un montón de dinero y volver a diseñar su aplicación para reducir la latencia de la aplicación de ~ 1 milisegundo para decir ~ 100 microsegundos (una mejora de 10x), en cuyo caso la latencia total para el usuario se reduciría a ~ 500.15 milisegundos ( una mejora de casi 0%). O podría pensar en formas de aprovechar HTTP 1.1 / 2 / SPDY, CDN, etc. y buscar la latencia de ~ 500 milisegundos .

Por ej. – configurar un par de máquinas en AWS / GCE / en la región de Asia Pacífico. Use nginx como equilibrador de carga para un par de instancias de su servidor de aplicaciones. Y luego haga que su servidor de aplicaciones configure una conexión DB a su base de datos en Nuevo México. Al igual que –

Ahora, consideremos una respuesta de solicitud típica:

1. Búsqueda de DNS del nombre de host – basado en la dirección de retorno de la ubicación de los clientes de su equilibrador de carga APAC – tiempo ~ 50 microsegundos .
2. Establezca una conexión TCP con el equilibrador de carga nginx en Singapur (el tiempo de ida y vuelta es de ~ 35 milisegundos o ~ 17.5 milisegundos por trayecto), un total de ~ 52.5 milisegundos .
3. Envíe una solicitud y espere una respuesta: ~ 35 milisegundos .
4. Ahora su servidor de aplicaciones necesita enviar una consulta a través de una conexión TCP existente a su base de datos en Nuevo México. Entonces, desde el equilibrador de carga a su servidor de aplicaciones a su base de datos y viceversa, digamos 1 milisegundo + 200 milisegundos = ~ 201 milisegundos.

Entonces, sin cambiar su código, simplemente al volver a implementar las cosas, obtendrá una latencia de ~ 288.55 milisegundos . ¿Cuál es una mejora sustancial sobre el original ~ 500.05 milisegundos … que no es tan malo para el trabajo de una mañana eh? :]

Descargos de responsabilidad –

1. Soy terrible en matemáticas, así que siempre verifica mis cálculos
2. Este es un ejemplo muy ingenioso que solía ilustrar las latencias típicas que enfrentan la mayoría de las aplicaciones. Puede o no aplicarse a sus requisitos.
3. Todos mis números están basados ​​en promedios. Nunca use promedios en la vida real. Usa percentiles.
4. Finalmente, medir, medir, medir. Las métricas son súper importantes. Las métricas son tu amigo. Cuanto más midas, menos sufrirás. Nunca adivine: las suposiciones me han causado más dolor que cualquier otra cosa en toda mi vida.
5. No he cubierto conexiones persistentes HTTP, conexiones paralelas, almacenamiento en caché de resultados de DNS, etc.