¿Qué tan bien funcionan juntos nginx y memcached?

Tenemos una aplicación web basada en Java EE que se ejecuta en un clúster de servidores de aplicaciones Glassfish . El tráfico entrante será principalmente solicitudes RESTful para representaciones basadas en XML de los recursos de nuestra aplicación, pero quizás el 5% del tráfico podría ser para representaciones basadas en JSON o XHTML / CSS.

Ahora estamos investigando soluciones de equilibrio de carga para distribuir el tráfico entrante entre las instancias de Glassfish en el clúster. También estamos investigando cómo descargar el clúster usando memcached, un mapa de hash distribuido en memoria cuyas claves serían los nombres de recursos REST (por ejemplo, "/ user / bob", "/ group / jazzlovers") y cuyos valores son las representaciones XML correspondientes.

Un enfoque que parece prometedor es matar a ambas aves de un tiro y usar el servidor HTTP nginx / proxy inverso liviano y rápido . Nginx manejaría cada solicitud entrante buscando primero su URI en memcached para ver si ya existe una representación XML no vencida. Si no, nginx envía la solicitud a una de las instancias de Glassfish. El módulo nginx memcached se describe en esta breve reseña .

¿Cuál es su impresión general con nginx y memcached utilizados de esta manera, qué tan contento está con ellos? ¿Qué recursos encontró más útiles para aprender sobre ellos? Si los probó y no se ajustaban a sus propósitos, ¿por qué no y qué utilizó en su lugar?

Nota: aquí hay una pregunta relacionada . Antes de saber acerca de ServerFault, pregunté esto en StackOverflow .

Editar: Todas las respuestas aquí hasta ahora han sido bastante útiles, aunque no hubo experiencia directa. Esta respuesta finalmente apareció en StackOverflow, y fue bastante optimista en la configuración nginx / memcached.

Realmente debería usar un servidor de caché frente a sus servidores web. Recomiendo Varnish-cache. Lo usamos en el trabajo con el sitio web más grande y activo de Escandinavia. Reemplazamos 13 cajas de calamar altamente cargadas con 1 caja de barniz y 1 de repuesto.

Comparé una aplicación simple en mi sitio web privado, y pasó de 9 solicitudes por segundo a más de 2000.

Usted decide cuánto tiempo guarda las cosas en la memoria, puede hacerlo hasta el final de los tiempos y luego simplemente enviar una solicitud de purga http al servidor de caché cuando cambien los datos.

Mi opinión personal, por experiencia, es que si está utilizando un equilibrador de carga, desea limitar esa casilla por completo a las funciones de equilibrio de carga. Hacer que su equilibrador de carga sirva contenido, incluso desde un caché, degrada la funcionalidad de equilibrio de carga en situaciones de alta carga (más conexiones permanecen activas durante más tiempo, reduciendo la capacidad general y el rendimiento).

Aconsejaría que la aplicación misma realice la búsqueda y sirva el contenido en caché y deje que el equilibrador de carga haga su trabajo. Dicho esto, nginx no es perfecto cuando se trata de equilibrar la carga, solo ofrece un algoritmo round-robin muy básico. Recomendaría haproxy en su lugar. Si necesita servicios de descifrado SSL por adelantado, nginx funciona bien sentado frente a haproxy, en mi experiencia.

Creo que irá a un callejón sin salida en caso de que necesite cosas como equilibrio de carga, alta disponibilidad, etc.

Además, tenga en cuenta esta situación: cuando el usuario está autorizado, la página tiene un aspecto diferente, con características adicionales disponibles e individualizadas para cada usuario. Las URL son las mismas para la conveniencia de vincular, etc. Por ejemplo, el sitio donde el usuario autenticado no necesita ingresar su nombre / captcha para comentarios o el sitio muestra su nombre de usuario en la parte superior, cuando está conectado (como servidor predeterminado). En tales casos, nginx será inutilizable, porque no puede distinguir entre usuarios autenticados y no autenticados.

Si no necesita SSL, le sugiero que ejecute Varnish. Ha sido diseñado como HTTP Accelerator, no como servidor web o proxy. Si necesita SSL, ejecute nginx en la parte superior como acelerador SSL y barnice como acelerador HTTP simple, porque Varnish no puede manejar SSL.

Creo que la elección del servidor de almacenamiento en caché es específica de la aplicación y no puede hacer comentarios generalizados al respecto sin un análisis en profundidad de la aplicación.

Mi elección es haproxy. ¡Proxy inverso muy pequeño y muy rápido, pero no es proxy de caché! Yo uso para mi sistema de caché "Squid Web Proxy"

CACHE /squid/ -> Load-balancing /Haproxy/ -> WEB I /lighttpd/
                                          -> WEB II /lighttpd/
                                          -> WEB III /lighttpd/

Este trabajo es perfecto para mi sistema web.