apache - lighttpd ventajas y desventajas

apache+lighttpd front-proxy concept (5)

Con el fin de aligerar la carga de Apache, la gente a menudo sugiere usar lighttpd para servir contenido estático.

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

En esta configuración, Apache pasa las solicitudes de contenido estático de vuelta a lighttpd a través de mod_proxy, al tiempo que sirve solicitudes dinámicas.

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

Si todavía tiene el poder de servir contenido estático y dinámico desde la misma máquina (como lo hacen en el artículo al que hace referencia ), entonces realmente no veo sentido en esa configuración.
Tal vez reduzca 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 reducirá la carga disponible para apache ...
Tal vez Lighttpd IO access es más ligero, que el de Apache 1.3, pero ¿por qué no simplemente cambiar a Apache 2 o Lighttpd por completo? Y si el rendimiento realmente comienza a ser malo, aloje los archivos estáticos en otra máquina (media.sudominio.com).

Mi pequeña introducción a cómo puedes hacer una configuración de rendimiento se encuentra aquí: Implementando Django -> desplázate a Scaling una página antes del final

No sé mucho sobre el funcionamiento interno de Apache, pero una explicación que he visto es acerca de 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 demasiada memoria caché y muy poco para aplicaciones. Si los separa a diferentes procesos, cada uno optimizará para el tipo de carga.

Actualmente, lo que estoy haciendo es usar nginx como front end. Es realmente rápido y ligero, y está específicamente diseñado como un proxy frontend; pero también sirve archivos estáticos. De hecho, dado que también puede invocar procesos FastCGI, puede deshacerse de Apache y obtener los beneficios de los procesos de archivos divididos / aplicaciones. (y hay algo de magia memcached extra que se ve absolutamente genial)

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

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

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

Lo que verá es que las personas usan un servidor web liviano como Nginx como un servidor frontend para enviar archivos estáticos y URL dinámicas de proxy a Apache. O bien, puede ejecutar Varnish o Squid como una interfaz de proxy inverso de almacenamiento en caché, para que todos los archivos estáticos de alto tráfico (es decir, imágenes, CSS, etc. y cualquier página dinámica a la que desee enviar encabezados de caché) se publiquen. de la memoria

Apache también se puede optimizar para servir archivos estáticos, con frecuencia cuando escucho que la gente se queja de Apache, realmente no saben cómo configurarlo. Solo han usado el MPM prefork (frente a subprocesos o trabajador) y tienen todo tipo de módulos habilitados (generalmente se ejecutan desde un paquete Apache de disipador de cocina de distribución de Linux que construye todo como módulos y se predetermina para habilitar 10-20 módulos o más). Ajusta Apache desactivando módulos innecesarios / características estúpidas como soporte para .htaccess (que hace que Apache explore el sistema de archivos en cada solicitud) primero. (También puedes ejecutar dos instancias de Apache, con un Apache "ligero" como frontend que se asemeja a un Apache "pesado" para solicitudes dinámicas ... tal vez tu interfaz esté enhebrada pero tu backend es anterior porque tienes que ejecutar thread-insafe módulos externos como mod_php)

Re:

Ya que todavía tiene un proceso de apache generado para cada solicitud que entra, ¿cómo impacta positivamente la carga? Por lo que puedo ver, el tamaño del proceso Apache que procesa su solicitud a través de lighttpd es tan grande como lo sería si estuviera sirviendo el archivo en sí.

Si está generando procesos en cada solicitud, 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 esa 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 interno para una solicitud determinada (¿cuánto procesamiento está haciendo el servidor?) Que con el uso de memoria informado por el sistema operativo.

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

Probablemente podría llegar a una "configuración de pesadilla" para Apache que haría más lento el servicio de archivos estáticos que el envío de esas solicitudes a un back-end Lighttpd, pero implicaría habilitar funciones costosas como .htaccess en Apache que están deshabilitadas en Lighttpd, entonces en realidad no sería justo.

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