Apache + lighttpd concepto de proxy frontal

Question

Para aligerar la carga de Apache, las personas a menudo sugieren usar lighttpd para ofrecer contenido estático.

por ejemplo http://www.linux.com/feature/51673

En esta configuración, Apache pasa las solicitudes de contenido estático de nuevo a lighttpd a través de mod_proxy, mientras atiende las solicitudes dinámicas.

Mi pregunta es: ¿cómo reduce esto la carga en el servidor? Dado que aún tiene un proceso de apache generado para cada solicitud que llega, ¿cómo afecta esto positivamente a la carga? Por lo que puedo ver, el tamaño del proceso de Apache que envía su solicitud a través de lighttpd es tan grande como lo sería si estuviera sirviendo el archivo en sí.

Answer 1

Ejecutar Lighttpd detrás de Apache para servir archivos estáticos ciertamente me parece muy interesante. Apache aún tiene que desempaquetar los paquetes HTTP y analizar la solicitud a través de su árbol de análisis, enviar solicitudes de proxy, y luego Lighttpd tiene que volver a desempaquetar, golpear el sistema de archivos y enviar los archivos a través de Apache. Nunca he escuchado de alguien que use una configuración como esta en producción.

Lo que verá es gente que usa un servidor web ligero como Nginx como frontend Servidor para servir archivos estáticos y URL dinámicas de proxy a Apache. O puede ejecutar Varnish o Squid como una interfaz de proxy inversa de almacenamiento en caché, de modo que todos sus archivos estáticos de alto tráfico (es decir, imágenes, CSS, etc. y cualquier página dinámica que ' está dispuesto a enviar encabezados compatibles con la memoria caché para) se ofrecen sin memoria.

Apache también puede optimizarse para que sirva archivos estáticos. Muy a menudo, cuando escucho a las personas quejarse de Apache, realmente no saben cómo configurarlo. Solo han usado el MPM prefork (en lugar de subprocesos o de trabajo) y tienen todo tipo de módulos habilitados (generalmente se ejecutan desde el paquete Apache del fregadero de cocina de una distribución de Linux que construye todo como módulos y valores predeterminados para habilitar 10-20 módulos o más). Ajuste Apache desactivando módulos innecesarios / funciones estúpidas como la compatibilidad con .htaccess (¡lo que hace que Apache analice el sistema de archivos en cada solicitud!) Primero. (También puedes ejecutar dos instancias de Apache, con un " ligero " Apache como frontend que los proxies a un " pesado " Apache para solicitudes dinámicas ... tal vez tu frontend esté enlazado pero tu backend está prepalado porque tienes que ejecutar thread - módulos externos no seguros como mod_php.)

Re:

  

Ya que todavía tienes un proceso de apache   generado para cada solicitud que viene   en, ¿cómo afecta esto positivamente   ¿la carga? De lo que puedo ver el tamaño.   del proceso de Apache que es su proxy   Solicitud a través de lighttpd es tan grande   como lo sería si estuviera sirviendo al   archivo en sí.

Si está generando procesos en cada solicitud, eso significa que está utilizando el MPM prefork. Tenga en cuenta que cuando el sistema operativo informa el uso de memoria para cada uno de estos procesos, no toda la memoria está conectada, muchos de esos procesos están inactivos. Y cuando habla de velocidad, le preocupa más el análisis de solicitudes y las ramas de código internas para una solicitud determinada (¿cuánto procesamiento está realizando el servidor?) Que el uso de memoria informado por el sistema operativo.

Por ejemplo, si habilitas algo como mod_php, entonces cada uno de esos procesos de trabajo aumentará instantáneamente en unos 20-40M (dependiendo de lo que esté habilitado en tu intérprete de PHP), pero eso no significa que Apache esté usando que la memoria en las solicitudes estáticas. Por supuesto, si está optimizando su servidor para la máxima concurrencia en pequeños archivos estáticos, entonces habilitar mod_php aún sería muy malo, no podrá integrar casi la misma cantidad de procesos prefork en la RAM.

Probablemente podría encontrar una " configuración de pesadilla " para Apache, eso lo haría más lento en el servicio de archivos estáticos que enviar esas solicitudes a un Lighttpd backend, pero implicaría habilitar funciones costosas como .htaccess en Apache que están deshabilitadas en Lighttpd, por lo que no Realmente sea justo.

Answer 2

1. Si aún tiene el poder para servir el contenido estático y dinámico de la misma máquina (como en su artículo referenciado do), entonces realmente no veo ningún punto en esa configuración.
2. Tal vez reduce la carga de Apache, porque no tiene que hacer IO en el disco, pero aumentará la carga de Lighttpd en la misma máquina y, por lo tanto, reducirá la carga disponible para apache ...
3. Tal vez el acceso a Lighttpd IO sea más ligero que el de Apache 1.3, pero ¿por qué no cambiar a Apache 2 o Lighttpd por completo? Y si el rendimiento realmente empieza a chupar, hospede los archivos estáticos en otra máquina (media.yourdomain.com).

Aquí se encuentra una pequeña introducción de cómo puede hacer una configuración performante: Implementación de Django - > desplácese hasta Scaling alguna página antes del final

Answer 3

No sé mucho sobre el funcionamiento interno de Apache, pero una explicación que he visto es sobre la presión de la memoria. En resumen, Apache intenta equilibrar la memoria que utiliza para el almacenamiento en caché y para las páginas dinámicas; pero generalmente termina con demasiado caché y muy poco para las aplicaciones. Si los separa en diferentes procesos, cada uno se optimizará para el tipo de carga.

Actualmente, lo que estoy haciendo es usar nginx como extremo delantero. Es realmente rápido y ligero, y está diseñado específicamente como un proxy de frontend; pero también sirve archivos estáticos. De hecho, dado que también puede llamar a los procesos FastCGI, podría deshacerse de Apache y aún así obtener los beneficios de los procesos de archivos / aplicaciones divididos. (y hay algunos magic memcached que se ve absolutamente genial)

(Sí, lighttpd también se puede usar como interfaz para Apache y / o FastCGI)

Answer 4

No tiene un proceso de Apache generado para cada solicitud: los archivos estáticos (imágenes y similares) se obtienen directamente de lighttpd.

Answer 5

Use Apache MPM Worker fastcgi para reducir el uso de memoria del servidor. MPM worker sirve mejor el contenido estático que Prefork y está casi a la par con lighttpd cuando se trata de contenido estático.