Barniz -> Nginx -> Apache una buena idea?

10

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!

apache-2.2 nginx architecture varnish Zoran Zaric
fuente

Respuestas:

8

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.

McJeff
fuente
Sí, esta es una muy buena idea, ya que el barniz debería ser bastante rápido para esto
Zoran Zaric
6

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

mogsie
fuente
Si lo que está sirviendo contenido para barnizar lo codifica en gzip, entonces barniz lo pasará a gzipped sin quejarse: varnish-cache.org/wiki/FAQ/Compression Lo único que no hace el barniz es tomar contenido que no está comprimido de la memoria caché aplicación y reservarlo comprimido. ¿Es este tu entendimiento también?
ewalk
La única vez que ejecuta nginx frente al barniz es cuando está usando ESI. Como no puede realizar el ensamblaje ESI desde páginas comprimidas, y Varnish no comprimirá una página ensamblada, Nginx se coloca delante de Varnish para proporcionar esa compresión. Si el origen sirve el contenido comprimido, Varnish pasará esos datos al cliente en forma comprimida.
user6738237482
Sí, ESI es una de las razones por las que recomendaría esta configuración, pero supongo que si su backend se comprime y no usa ESI, podría prescindir de nginx, ya que creo que el barniz puede manejar una gran cantidad de tráfico sin rompiendo a sudar.
mogsie
@ user6738237482, nginx admite la terminación SSL, Varnish no. De hecho, estar frente a algo como barniz o Apache es exactamente para lo que nginx fue diseñado originalmente, como un servidor proxy rápido y liviano.
rmalayter
4

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.

Tony
fuente
sí, podría cambiar de apache a nginx para rails, pero dar a los clientes la capacidad de usar archivos .htaccess es un + para apache, al menos para php.
Zoran Zaric
2

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.

Miguel
fuente
3
Sabes que el barniz no habla ssl ¿verdad?
Mike
1

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é.

Go2linux
fuente
0

No es una buena idea a menos que necesite algo como ESI. Nginx tiene su propio sistema de almacenamiento en caché que funciona mejor .

VBart
fuente
Sé que esta es una respuesta anterior, pero desafortunadamente ese enlace ya no está disponible, por lo que no puedo verificar su reclamo. En mi experiencia, Varnish es difícil de superar en su velocidad y flexibilidad como proxy inverso.
Martijn Heemels
@MartijnHeemels web.archive.org/web/20130501222206/http://todsul.com/… y hay otro punto de referencia: nbonvin.wordpress.com/2011/03/24/…
VBart
-1

Apache se puede usar para terminar SSL (descifrar), verifique http://noosfero.org/Development/Varnish#SSL

brauliobo
fuente
1
Evite publicar enlaces como respuestas, ya que es probable que su respuesta pierda todo significado cuando sea afectada por linkrot . Considere editar su respuesta e incluir partes relevantes del enlace que ha proporcionado en su respuesta. De todos modos, deje el enlace en su lugar como referencia.
Bryan