Equilibrio de carga en Amazon EC2?

Hemos estado luchando con HAProxy desde hace unos días en Amazon EC2; la experiencia hasta ahora ha sido genial, pero estamos atascados en exprimir más rendimiento del balanceador de carga de software. No somos exactamente expertos en redes Linux (normalmente somos una tienda.NET), pero hasta ahora nos hemos mantenido por nuestra cuenta, intentando establecer ulimits adecuados, inspeccionando los mensajes del kernel y tcpdumps para detectar cualquier irregularidad. Sin embargo, hasta ahora, hemos alcanzado una meseta de aproximadamente 1,700 solicitudes / seg, momento en el que el cliente abundan los tiempos de espera (hemos estado usando y ajustando httperf para este propósito). Un compañero de trabajo y yo estábamos escuchando el podcast más reciente de Stack Overflow, en el que los fundadores de Reddit notan que todo su sitio se ejecuta en un nodo HAProxy, y que hasta ahora no se ha convertido en un cuello de botella. ¡Ack! O no hay de alguna manera ver que muchas solicitudes concurrentes, estamos haciendo algo horriblemente mal, o la naturaleza compartida de EC2 está limitando la pila de red de la instancia de Ec2 (estamos utilizando una gran tipo de instancia). Teniendo en cuenta el hecho de que tanto Joel como los fundadores de Reddit están de acuerdo en que la red probablemente será el factor limitante, ¿es posible que esa sea la limitación que estamos viendo?

Cualquier pensamiento es muy apreciado!

Edit Parece que el problema real no fue, de hecho, con el nodo de balanceador de carga! El culpable fue en realidad los nodos que ejecutan httperf, en este caso. A medida que httperf construye y rompe un socket para cada solicitud, gasta una buena cantidad de CPU tiempo en el núcleo. A medida que aumentamos la tasa de solicitud, el TCP FIN TTL (siendo 60s por defecto) estaba manteniendo los sockets durante demasiado tiempo, y el valor predeterminado de ip_local_port_range era demasiado bajo para este escenario de uso. Básicamente, después de unos minutos del nodo cliente (httperf) creando y destruyendo constantemente nuevos sockets, el número de puertos no utilizados se agotó, y las 'solicitudes' posteriores se errorearon en esta etapa, produciendo números de solicitud/segundo bajos y una gran cantidad de errores.

También tuvimos miré nginx,pero hemos estado trabajando con RighScale, y tienen scripts para HAProxy. Ah, y tenemos un plazo demasiado apretado [por supuesto] para cambiar los componentes a menos que resulte absolutamente necesario. Afortunadamente, estar en AWS nos permite probar otra configuración usando nginx en paralelo (si está garantizado) y hacer el cambio durante la noche más adelante.

Esta página describe cada una de las variables sysctl bastante bien (ip_local_port_range y tcp_fin_timeout se ajustaron, en este caso).