optimize - ¿Por qué Apache Event MPM está funcionando mal?

optimize apache

Question

El Event MPM no es exactamente el mismo diseño que Nginx, pero fue claramente diseñado para hacer que los keepalives sean más sostenibles y el envío de archivos estáticos más rápido. Mi entendimiento es que el MPM del evento es un nombre poco apropiado porque:

1. Aunque la conexión se pasa a kqueue / epoll,
2. ciertos módulos muy importantes como mod_gzip y mod_ssl bloquearán / consumirán un hilo hasta que se complete la respuesta,
3. y ese es un problema para archivos grandes, pero probablemente no para documentos HTML generados por PHP, etc.

Desafortunadamente, Apache sigue perdiendo cuota de mercado, y la mayoría de los puntos de referencia son perjudiciales para el evento MPM. ¿Son defectuosos los puntos de referencia, o el evento MPM realmente hace tan mal contra Nginx? Incluso con estas limitaciones, bajo tráfico normal (no malicioso) y archivos más pequeños, debería ser algo competitivo con Nginx. Por ejemplo, debería ser competitivo el servicio de documentos generados por PHP a través de php-fpm en conexiones lentas, ya que el documento se almacenará en búfer (incluso si es ssl''d y gzip''d) y se enviará de forma asíncrona. Las conexiones SSL y no SSL que utilizan compresión o no deben funcionar de manera significativamente diferente a como lo harían en Nginx en dicha carga de trabajo.

Entonces, ¿por qué no brilla en varios puntos de referencia? ¿Qué tiene de malo? ¿O qué hay de malo con los puntos de referencia? ¿Un sitio importante lo está utilizando como una apelación a la autoridad que puede realizar?

Answer 1

Es más lento que nginx porque Apache con el evento MPM es (muy) aproximadamente equivalente a un proxy HTTP controlado por eventos (nginx, barniz, haproxy) frente a Apache con el MPM trabajador. El evento es un trabajador, pero en lugar de entregar cada nueva conexión a un subproceso durante su vida útil, los subprocesos del MPM del evento entregan la conexión a un subproceso secundario que la empuja a una cola o la cierra si keep-alive está desactivada o ha caducado.

El beneficio real del evento sobre el trabajador es el uso de recursos. Si necesita mantener 1.000 conexiones simultáneas, el MPM trabajador necesita 1.000 subprocesos, mientras que el evento MPM puede funcionar con 100 subprocesos activos y 900 conexiones inactivas administradas en la cola de eventos. El evento MPM usará una fracción de los recursos del trabajador MPM en esa hipótesis, pero la desventaja aún está ahí: cada una de esas solicitudes se maneja mediante un subproceso separado que debe ser programado por el núcleo y, como tal, incurrirá en el costo de cambiando de contexto.

Por otro lado, tenemos nginx que utiliza el modelo de evento como su planificador. Nginx simplemente procesa tanto trabajo en cada conexión como puede antes de pasar a la siguiente. No se requiere cambio de contexto adicional.

El único caso de uso en el que el evento MPM realmente brilla es manejar una configuración en la que tiene una aplicación pesada que se ejecuta en Apache y conservar los recursos de subprocesos inactivos durante el mantenimiento de la vida, implementaría un proxy (como nginx) delante de apache. Si su interfaz no tiene otro propósito (p. Ej., Contenido estático, envío a otros servidores, etc.), el evento que MPM maneja a la perfección de ese caso de uso y elimina la necesidad de un proxy.

Answer 2

Para mí, las diferencias operativas dominantes son las siguientes:

• los manejadores (los complementos responsables de generar la respuesta) son síncronos: si están realizando un cálculo o I / O, atarán un hilo
• el núcleo debe usar bloqueos de subprocesos para proteger estructuras de datos clave porque es multihilo para admitir tantas de estas solicitudes síncronas

Es por eso que en los servidores de volúmenes muy altos como nginx (o el Servidor de tráfico Apache o cualquier proxy comercial / de alto rendimiento moderno) generalmente sale adelante.

IMO Las viñetas en su pregunta están un poco fuera de lugar, SSL y deflate realmente no contribuyen mucho a las diferencias aquí, ya que ambos son filtros que no contribuyen realmente a problemas de escalabilidad o incluso que vinculan a httpd con su API tradicional. Ciclo de vida de una solicitud o conexión. Filtros como estos (frente a los controladores, o el filtro central responsable de la E / S de bajo nivel) son probablemente las cosas menos ligadas al modelo de procesamiento.

Pero tampoco creo que funcione tan mal en comparación con todos, excepto con las cargas de trabajo más extremas o los sistemas extremadamente restringidos. La mayoría de los puntos de referencia que he visto son de muy baja calidad, por una razón u otra.

Creo que, en gran medida, la gente quiere que lo que ellos llaman un servidor web hoy en día sea un proxy para un servidor de aplicaciones más sofisticado (Java EE, PHP, etc.) y un servidor diseñado para mover la E / S más eficientemente sin la API. .