EC2 Problemas de rendimiento de ELB

Question

Dos preguntas sobre EC2 ELB:

Primero es cómo ejecutar correctamente las pruebas de JMeter. He encontrado el siguiente http://osdir.com/ml/jmeter-user.jakarta.apache.org/2010-04/msg00203.html, que básicamente dice que para establecer -Dsun.net.inetaddr.ttl = 0 al iniciar JMeter (que es fácil) y el segundo punto que hace es que el enrutamiento es por ip, no por solicitud. Así que, aparte de comenzar una granja de instancias de jmeter, no veo cómo evitar eso. Cualquier idea es bienvenida, o posiblemente estoy leyendo mal la explicación (?)

Además, tengo un servicio web que realiza una llamada al servidor a otro servicio web en Java (y ambos detrás de ELB), por lo que Estoy usando HttpClient y es MultiThreadedHttpConnectionManager, donde proporciono algunas rutas de gran tamaño para el valor del host en el administrador de conexión. Y me pregunto si eso romperá el comportamiento de equilibrio de carga ELB porque las conexiones están en caché (y también, todas las solicitudes se originan en la misma máquina). Puedo cambiar para usar un nuevo HttpClient cada vez (tipo de cojo) pero eso no evita el hecho de que todas las solicitudes se originan en un pequeño número de hosts.

Antecedentes: estoy en el proceso de probar un servicio utilizando ELB en EC2 y el tráfico no se distribuye de manera uniforme (la mayoría del tráfico a 1-2 nodos, casi ningún tráfico a 1 nodo, no hay tráfico a un 4º nodo). Y entonces los problemas anteriores son los posibles culpables que he identificado.

Answer 1

He tenido problemas muy similares. Una cosa es que el ELB no escala bien bajo carga explosiva. Entonces, cuando intentas probarlo, no se escala de inmediato. Le lleva mucho tiempo avanzar. Otra desventaja es el hecho de que usa un CNAME como la búsqueda de DNS. Esto solo te va a retrasar. Hay más problemas de rendimiento que puede investigar.

Mi recomendación es usar haproxy. Tienes mucho más control y te gustará el rendimiento. He estado muy feliz con eso. Uso heartbeat para configurar un servidor redundante y estoy listo para empezar.

Además, si planeas hacer SSL con el ELB, sufrirás más porque el rendimiento me parece inferior.

Espero que ayude a algunos. Cuando se trata de eso, AWS me ha dicho personalmente que las pruebas de carga del ELB realmente no funcionan, y si planea lanzar con una gran cantidad de carga, debe informarles para que puedan escalarlo antes de tiempo. .

Answer 2

No dice cuántas instancias de jmeter está ejecutando, pero en mi experiencia debería ser alrededor de 2 veces la cantidad de AZ que está escalando. Incluso entonces, probablemente verá cargas desequilibradas: es muy raro ver la carga escalada exactamente a través de su flota de back-end.

Puedes ayudar (un poco) ejecutando tus instancias de jmeter en diferentes regiones.

Otro factor es la duración de la prueba. A los ELB les lleva algo de tiempo escalar; en general, puedes decir cuántas instancias se ejecutan haciendo un nslookup contra el nombre ELB. Comprenda sus patrones de escala y construya pruebas alrededor de ellos. (Por lo tanto, si lleva 20 minutos agregar otra instancia al grupo ELB, incluya un calentamiento de 25-30 minutos para su prueba). También obtiene AWS para "precalentar" el grupo ELB si es necesario.

Si su tamaño de grupo ELB es suficiente para su prueba y puede verificar que el grupo no cambia durante una prueba, siempre puede intentar ejecutar las pruebas directamente contra las IP ELB, es decir, equilibrar manualmente el tráfico.

No estoy seguro de lo que espera que suceda con el segundo nivel de llamadas: si está abriendo una conexión y volviéndola a utilizar, obviamente no hay forma de escalarla a través de instancias sin cerrar & abriendo la conexión. ¿Se están ejecutando estas llamadas en el mismo conjunto de servidores o en un conjunto diferente? Puedes crear un ELB interno y usar ese punto final para conectarte, pero no estoy seguro de que eso ayude en el escenario que describes.