apache + lighttpd concepto de proxy frontal

Question

Para aclarar la carga de Apache, a menudo la gente sugiere usar lighttpd para servir contenido estático.

p. Ej. http://www.linux.com/feature/51673

En esta configuración, Apache transfiere las solicitudes de contenido estático a lighttpd a través de mod_proxy, mientras se atienden 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í.

Answer 1

Correr Lighttpd detrás Apache para servir archivos estáticos ciertamente parece Braindead a yo. 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 usted verá, es la gente que usa un servidor web ligero como Nginx como servidor frontend para servir archivos estáticos y dinámicos URL de proxy para Apache.O bien, puede ejecutar Varnish o Squid como una interfaz de proxy inverso en caché, de modo que todos sus archivos estáticos de alto tráfico (es decir, imágenes, CSS, etc. y páginas dinámicas a las que desee enviar encabezados de caché) son servido de memoria.

Apache también se puede optimizar para servir archivos estáticos, con frecuencia cuando escucho a personas quejarse 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 crea todo como módulos y de forma predeterminada habilita 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:.

Puesto que todavía tienen un proceso de Apache generado para cada solicitud que viene en , ¿cómo afecta esto 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 como lo sería si estuviera sirviendo el archivo .

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, cada uno de esos procesos de trabajo aumentará instantáneamente en unos 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 una concurrencia máxima en pequeños archivos estáticos, habilitar mod_php seguirá siendo muy malo, no podrá incluir casi tantos procesos prefork en la memoria RAM.

probablemente podría llegar a una "configuración de pesadilla" para Apache que habría que sea realmente más lento que sirve archivos estáticos de proxy a esas peticiones a un backend Lighttpd, pero implicaría la habilitación de funciones caros como .htaccess de Apache en el que están deshabilitados en Lighttpd, por lo que no sería justo.

Answer 2

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

Answer 3

1. Si todavía tiene el poder para servir contenido estático y dinámico de la misma máquina (ya que en su referenced article hacer), entonces realmente no ven ningún punto en el que la configuración.
2. Tal vez reduce la carga de Apache, ya que no tiene que hacer IO en el disco, sino que aumentará la carga de Lighttpd en la misma máquina y reducir así la carga disponibles a Apache. ..
3. Tal vez Lighttpd IO acceso 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).

Me pequeña introducción a cómo se puede hacer una instalación performant se encuentra aquí: Deploying Django -> desplazamiento para Scaling alguna página antes del final

Answer 4

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 interfaz. 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 un poco de sobrepeso memcached magic que se ve absolutamente genio)

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

Answer 5

Usar Apache MPM Worker fastcgi esto disminuirá 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.