Estoy pensando en la arquitectura para un nuevo servidor web. ¿Sería una buena idea tener Varnish como caché frente a Nginx como proxy inverso y servir archivos estáticos frente a apache para todos los trabajos pesados?
Voy a ejecutar aplicaciones php y ruby on rails.
¿Habrá demasiada sobrecarga pasando solicitudes php a apache a través de otros dos procesos?
¡Muchas gracias!
Respuestas:
Si, es valido. Mi enfoque personal sería usar Varnish por adelantado y usar VCL para dividir el tráfico entre solicitudes NGINX estáticas y su trabajo pesado (ya sea Apache o Passenger o ... no importa). Esto es especialmente cierto si está en la misma máquina ya que no necesita la sobrecarga adicional. No necesariamente te compra nada.
Varnish (todavía) no admite la compresión gzip, por lo que podría ser una idea intercambiarlo con nginx en el frente para comprimir lo que el barniz devuelve. Dado que varnish y nginx no luchan por los mismos recursos (nginx usa CPU para la compresión gzip, mientras que barniz usa memoria) deberían funcionar sin problemas en la misma máquina.
Varnish ahora admite la compresión gzip , por lo que, a menos que necesite la terminación SSL (como se sugiere en los comentarios), sugeriría poner el barniz directamente en contacto con Internet.
Para http:
(internet) -> (barniz, gzip, caché, esi) -> (aplicación)
Para https:
(internet) -> (nginx, ssl) -> (barniz, gzip, caché, esi) -> (aplicación)
Si también quieres apache allí (para el ubicuo soporte mod_foobar), lo pondré entre el barniz y la aplicación
Actualización: actualizado para incluir soporte gzip en Varnish 3.0. Se agregó ssl / esi como se sugiere en los comentarios
La cantidad de gastos generales no debe ser significativa. Supongo que parte de la razón por la que desea tener estos dos niveles es por la escalabilidad; en cuyo caso lo más probable es que, en comparación con apache, el barniz y el nginx no funcionen muy duro.
Si tiene los tres niveles en una máquina, debería haber un impacto menor en el rendimiento antes de alcanzar la capacidad del servidor.
Como alternativa, ¿por qué no barnizar + nginx con pasajero? He usado esta configuración en el pasado y nginx con pasajeros es relativamente liviano y funcionó bastante bien. Podría valer la pena pensar si no estás casado con apache ejecutando tu pila de rieles.
Soy el administrador del sistema para una plataforma de comercio electrónico de inicio. Usamos varnish + nginx delante de nuestra pila PHP / apache y ha funcionado de maravilla.
Tenemos una aplicación de uso de memoria alta y la aplicación estaba usando alrededor de 15-20 gigas de RAM por nodo web y una vez que colocamos el barniz al frente ahora es de alrededor de 8 gig de RAM por nodo. Nunca se han disparado.
Así que lo recomiendo mucho.
Estoy ejecutando Drupal, con el módulo boost en un servidor Apache + PHP + MySQL, pero frente a ellos estoy usando Nginx con la función gzip-static activada, y estoy usando los resultados de boost para servir a los usuarios.
Y además de todo eso estoy usando barniz, todo en la misma PC, estoy teniendo buenos resultados.
También estoy usando Nginx para ajustar los encabezados que Drupal no hace muy bien para el caché.
No es una buena idea a menos que necesite algo como ESI. Nginx tiene su propio sistema de almacenamiento en caché que funciona mejor .
Apache se puede usar para terminar SSL (descifrar), verifique http://noosfero.org/Development/Varnish#SSL