Otro beneficio de Lighttpd frente a Apache

Question

Leí en un sitio que otro beneficio de tener Lighttpd frente a Apache es una menor cantidad de procesos secundarios. Lighttpd manejará las solicitudes de mantenimiento y de los clientes, mientras que los procesos secundarios de Apache pueden servir páginas dinámicas más rápido debido a la comunicación de muy baja latencia entre Lighttpd y Apache. Estoy intentando encontrar el enlace pero me cuesta.

Dado que ya tengo un servidor Lighttpd dedicado para mis contenidos estáticos (img, vid, css, js, html, etc.) y otro servidor Apache dedicado para mis páginas dinámicas (php), me gustaría implementar esta técnica si realmente tiene cierta ganancia de rendimiento.

1) ¿Alguien ha puesto un Lighttpd delante de Apache con el mismo propósito explicado anteriormente?
2) ¿Existe realmente una ganancia de rendimiento con esto? ¿Cuánto cuesta?
3) ¿Qué pasa con la sobrecarga de Lighttpd al manejar la solicitud a Apache? ¿Realmente vale la pena?

¡Gracias!

Answer 1

1. Servimos contenido estático de manera ligera y reenviamos las solicitudes dinámicas a Apache en el mismo servidor pero escuchando en otro puerto.
2. el "reenviar a Apache para dinámica" no se hizo con fines de rendimiento, sino simplemente para tener un único servidor desde el punto de vista del cliente, sirviendo a todo. Sin embargo, si puedes evitar el exceso de conexiones a Apache, es un buen beneficio adicional. Más conexiones = más procesos = más memoria (especialmente con mod_php). Así que no hay números, lo siento.
3. los gastos generales parecían insignificantes en comparación con el cerdo que es Apache

Dicho esto, deberías considerar el proxy inverso de Varnish en lugar de (o delante de) lighty como tu interfaz. Es muy rápido y eficiente. Especialmente interesante para almacenar en caché páginas dinámicas (o fragmentos de páginas, usando ESI), ayuda a reducir la carga del backend y absorber los picos de tráfico.

Y posiblemente use nginx (con PHP-FCGI) como backend en lugar de Apache (aunque es una tarea más complicada que agregar una interfaz Varnish) (nginx también se puede usar como interfaz, pero no es tan bueno como un proxy inverso dedicado como Barniz). Descargo de responsabilidad: no tengo experiencia en nginx;)

Answer 2

Solía ​​​​estar en la misma situación, demandando a lighttpd junto a apache) por reducir la carga en apache.

Es mejor ofrecer contenido estático con un servidor web ligero, ya que requiere menos recursos. También hay que mencionar que PHP requiere que Apache se ejecute en modo prebifurcado, lo que impide que Apache se ejecute de manera eficiente. Puede distribuir la carga entre dos servidores web configurados de manera diferente, cada uno de los cuales maneja el tráfico que mejor se adapta a sus necesidades.

Algunas notas de implementación:

Tienes tres opciones:

1. modifica tu código y segmenta el tráfico en la capa IP
2. No modifique su código y segmente el tráfico en la capa de aplicación (http).
3. hacer que uno de los servidores web pase las solicitudes que llegan al otro servidor web para realizar el servicio real

El primero es más rápido, el segundo requiere menos configuración, el tercero es como una mula.

Yo no consideraría la tercera opción si fuera usted, ya que viene con una pesadilla de configuración, además, si configura mal algo en el primer servidor web, nada funcionará y es más difícil detectar dónde está el problema.

En el pasado, necesitaba tener una solución urgentemente, así que elegí la opción 2 y utilicé un proxy inverso llamadolibrapara segmentar solicitudes según contenido estático/dinámico y distribuir la carga a los dos servidores web diferentes.

Aunque funciona, requiere monitorear activamente el contenido http, lo que afecta el rendimiento (se ejecuta un demonio adicional).

Con la opción 2, puede obtener un mejor rendimiento utilizando una IP adicional para contenido estático (static.domain.org) y hacer que los clientes consulten este static.domain.org para ver el contenido. Aún requerirá un proxy inverso, pero el proxy no tiene que verificar el encabezado Host: en ninguna de las solicitudes, por lo que será más rápido.

Aquí hay un fragmento de configuración de libra para su referencia:

ListenHTTP 
        Address 195.175.71.17
        Port 80
        Client 30
        RewriteLocation 2

        Service
                HeadRequire "^[Hh]ost:\s*www.nasa.gov$"
                URL "^/static/content"
                BackEnd
                        Address 127.0.0.1
                        Port 81
                        TimeOut 300
                End
        End
        Service
                HeadRequire "^[Hh]ost:\s*www.nasa.gov$"
                BackEnd
                        Address 127.0.0.1
                        Port 80
                        TimeOut 300
                End
        End
ListenHTTP