amazon-web-services - services - aws login
Entendiendo AWS ELB Latency (2)
Estoy dispuesto a entender exactamente lo que significa la estadística de latencia ELB proporcionada por CloudWatch.
Según los documentos:
- Latencia ELB: "Mide el tiempo transcurrido en segundos después de que la solicitud abandone el equilibrador de carga hasta que se reciba la respuesta".
Lo que no tengo claro al 100% es si la respuesta se amortigua o no al ELB antes de que se transfiera al cliente.
¿La declaración en los documentos significa:
- Latencia ELB: "Mide el tiempo transcurrido en segundos después de que la solicitud abandone el equilibrador de carga hasta que el cliente reciba la respuesta".
O:
- Latencia de ELB: "Mide el tiempo transcurrido en segundos después de que la solicitud abandona el equilibrador de carga hasta que se recibe la respuesta [por parte de ELB]".
Quiero comprender si una métrica pobre de CloudWatch de latencia máxima podría explicarse por tener un número significativo de usuarios en conexiones 3G por cable o, si en cambio, indica un problema subyacente con los servidores de aplicaciones que ocasionalmente responden a la desaceleración.
Parece ser una medida de cuánto tiempo tarda el servidor en generar su respuesta desde la perspectiva de ELB, sin tener en cuenta cuánto tiempo podría ser necesario para que ELB devuelva la respuesta al cliente.
Llegué a esta conclusión al revisar mis propios registros en una de mis aplicaciones, que utiliza ELB frente a otro equilibrador de carga, HAProxy, que a su vez está frente a los servidores de aplicaciones reales. (Esto puede parecer redundante, pero nos brinda varias ventajas sobre el uso de solo ELB o solo HAProxy).
Aquí está la configuración a la que me refiero:
ELB -->>-- EC2+HAProxy -->>-- EC2+Nginx (multipe instances)
HAProxy registra varias métricas de tiempo en cada solicitud, incluida una llamada Tr .
Tr: tiempo de respuesta del servidor (solo modo HTTP). Es el tiempo transcurrido entre el momento en que se estableció la conexión TCP con el servidor y el momento en que el servidor envió sus encabezados de respuesta completos. Muestra únicamente el tiempo de procesamiento de su solicitud, sin la sobrecarga de la red debida a la transmisión de datos.
Ahora, quédate conmigo para obtener una explicación de por qué tanta discusión de lo que HAProxy está haciendo aquí es relevante para ELB y la métrica de latencia.
A pesar de que HAProxy registra una cantidad de otros temporizadores relacionados con el tiempo que el proxy pasa esperando varios eventos en cada solicitud / respuesta, este temporizador Tr es el temporizador único en mis registros de HAProxy que se corresponde perfectamente con los valores registrados por la métrica de "Latencia" de Cloudwatch. para el ELB minuto por minuto, dé o tome un milisegundo o dos ... los demás son una gran variante ... por lo que sugeriría que esta métrica de ELB está registrando de manera similar el tiempo de respuesta de su servidor de aplicaciones, sin relación al tiempo adicional que se pueda requerir para devolver la respuesta al cliente.
Parece muy poco probable que el HAProxy y el ELB estén tan de acuerdo, de lo contrario, dada la definición de HAProxy del temporizador en cuestión, a menos que el temporizador de ELB esté midiendo algo muy similar a lo que HAProxy está midiendo, ya que estos sistemas están literalmente midiendo el rendimiento de los mismos servidores de aplicaciones exactos en las mismas solicitudes exactas.
Si su servidor de aplicaciones no realiza pruebas comparativas y registra los temporizadores de su propio rendimiento, puede considerar agregarlos, ya que (según mis observaciones) los valores altos para la métrica de latencia parecen sugerir que su aplicación puede tener una capacidad de respuesta problema que no está relacionado con la calidad de conexión del cliente.
Según el soporte de AWS:
Como el ELB (cuando está configurado con escuchas HTTP) actúa como un proxy (los encabezados de solicitud entran y se validan, y luego se envían al backend) la métrica de latencia comenzará a marcar tan pronto como los encabezados se envíen al backend hasta que el backend se envíe Las respuestas del primer byte.
En el caso de POST (o cualquier método HTTP cuando el cliente está enviando datos adicionales), la latencia estará marcada incluso cuando el cliente esté cargando los datos (ya que el backend necesita la solicitud completa para enviar una respuesta) y se detendrá una vez que el backend envíe la primera respuesta byte. Entonces, si tiene un cliente lento que envía datos, la latencia tomará en cuenta el tiempo de carga + el tiempo que tomó el backend para responder.