¡Este artículo se explicará tabla por tabla! Primero dé las ventajas y desventajas de Nginx y Apache, y luego analice las razones de la arquitectura y el modo
Análisis de ventajas y desventajas.
1.
Ventajas
de Nginx : 1. Nginx tiene buena concurrencia. Nginx utiliza epoll como el modelo basado en eventos en Linux. La forma de procesar las solicitudes es asíncrona y sin bloqueo. La capacidad de carga es mucho mayor que Apache, y Apache está bloqueando En el caso de una alta concurrencia, Nginx puede mantener fácilmente un bajo consumo de recursos y un alto rendimiento, y Apache es propenso a aumentar el número de procesos cuando el procesamiento de PHP es lento o la presión del front-end es alta, lo que niega el servicio
2. El rendimiento de nginx para procesar archivos estáticos es mejor que el de Apache
3. Nginx implica un alto grado de modularidad, escribir módulos es relativamente simple
4. La configuración de nginx es concisa, puede usar -t para probar la configuración una vez que se haya completado.
5. Nginx puede usarse como balanceador de carga, soportando carga de 7 capas
6. nginx en sí es un servidor proxy inverso, y puede usarse como un muy buen servidor proxy de correo
7.nginx puede realizar un reinicio en caliente
Desventajas:
1. La capacidad de Nginx para procesar archivos dinámicos, es decir, interactuar con el servidor PHP de fondo es promedio, y Apache es muy eficiente en el manejo de solicitudes dinámicas.
Acerca de la degradación detallada de nginx, puede consultar otro artículo del autor para obtener una comprensión inicial de Nginx
II.
Ventajas de Apache :
1. La reescritura de Apache es más fuerte que Nginx. En el caso de reescritura frecuente, use Apache
2. Debido a que Apache parece más largo que Nginx, puede tener menos errores y ser más estable
3. El soporte de PHP de Apache es relativamente simple, porque PHP era incluso un módulo en la arquitectura de Apache, y Nginx necesita ser usado con otros backends (como FastCGI)
4. La capacidad de Apache para manejar solicitudes dinámicas es relativamente fuerte, a nginx no le está yendo bien en este sentido
Desventajas:
1. Apache es más voluminoso que nginx, y su capacidad para hacer frente a una alta concurrencia es más débil que nginx
3. Resumen
Las ventajas y desventajas de Nginx y Apache se muestran en forma de tabla para su comparación.
| Compara objetos | nginx | apache |
|---|---|---|
| Capacidad para hacer frente a la alta concurrencia | Fuerte | Media |
| Capacidad para manejar solicitudes estáticas | Fuerte | Media |
| Capacidad para manejar solicitudes dinámicas | Media | Fuerte |
| Estabilidad | Media | Fuerte |
| Funciones ampliadas | Menos | Mucho |
| Utilización de recursos (rendimiento) | Mejor | Media |
| Soporte de CPU multinúcleo | Buen efecto | Efecto medio |
La diferencia entre página web estática y página dinámica Por favor, lea este artículo La diferencia entre página web estática y página dinámica
Análisis de arquitectura
¡Analizamos principalmente la arquitectura de Nginx y Apache en alta concurrencia y rendimiento! ! !
La diferencia entre Nginx y Apache se debe principalmente a que el modo de trabajo de Nginx es asíncrono y sin bloqueo, mientras que el modo de trabajo de Apache está bloqueando sincrónicamente
Implementación relacionada con la concurrencia
1. Modo de trabajo (método de procesamiento de solicitudes web, síncrono o asíncrono)
1.
La implementación de Nginx ----- modo de trabajo asíncrono nginx es que ngxin comienza a crear un proceso maestro, y luego el proceso maestro crea el proceso de trabajo La función es crear y detener procesos secundarios, y transferir solicitudes de usuario al proceso de trabajo, es decir, el proceso de trabajo es procesado realmente por la solicitud del usuario. Debido a que su modo de comunicación es una arquitectura asíncrona, un proceso de trabajo puede manejar múltiples solicitudes de usuario
2 .Apache ----- Synchronous
Aapache tiene varios modos de trabajo, pero sus métodos de comunicación de red son comunicación sincrónica, es decir, cada proceso o subproceso solo puede manejar la solicitud de un usuario , similar a nginx, Apache también se compone de un El control del proceso principal genera muchos procesos de trabajo (puede haber muchos subprocesos de trabajo bajo el proceso de trabajo), la carga del proceso principal crea procesos secundarios y programa las solicitudes de los usuarios, y es el proceso de trabajo (o el subproceso de trabajo) el responsable de procesar las solicitudes de los usuarios.
Aquí hay tres modos de trabajo de Apache, que son diagramas esquemáticos del modo prefork, el modo trabajador y el modo evento, que son todos modos de comunicación síncrona, es decir, ¡cada proceso o subproceso solo puede procesar la solicitud de un usuario al mismo tiempo! Sin embargo, cada modo tiene su escenario de uso correspondiente, por lo que no lo repetiré aquí.
Después de comparar los métodos de solicitud web, generalmente podemos entender por qué Nginx es mejor que Apache. Permítanme resumir mi Vista
Debido a que cada proceso de trabajo de Nginx puede manejar solicitudes de múltiples usuarios, el número de cambios de proceso de Nginx será muy pequeño y, por lo tanto, el cambio de contexto será menor, de modo que el sistema consume menos recursos. Y Apache necesita cambiar los procesos con frecuencia, por lo que los recursos consumidos por el cambio de procesos dificultan la mejora del rendimiento. En segundo lugar, cuando se enfrenta a una alta concurrencia, Apache necesita crear múltiples procesos o subprocesos. La creación de procesos y subprocesos también consume recursos del sistema, por lo que cuando se enfrenta a una alta concurrencia, nginx puede enfrentarlo fácilmente, mientras que Apache enfrenta una alta concurrencia. Dificil
Implementación relacionada con el rendimiento
2. Modelo basado en eventos (llame al proceso local para manejar el modo de E / S, bloqueando o no bloqueando) para
llevar a cabo la forma mencionada de procesar las solicitudes web, cuando el servidor recibe la solicitud web, el proceso principal enviará la solicitud y la asignará a la correspondiente proceso de trabajo En este punto, el proceso de trabajo comienza a procesar solicitudes web. Si el usuario solicita contenido en un archivo, el proceso de trabajo realizará operaciones de E / S.
Cuando se trata de operaciones de E / S, mencionemos brevemente aquí, bloqueo y no bloqueo. En primer lugar, el bloqueo del que estamos hablando aquí es el bloqueo de las operaciones de E / S
: cuando un proceso llama a una operación de E / S, debe esperar hasta que la operación de E / S complete el resultado devuelto. Si no hace nada durante el período de espera Sí, solo espere a que se complete la operación de E / S, luego se dice que es un proceso de bloqueo
sin bloqueo: cuando un proceso llama a la operación de E / S, no necesita esperar a que finalice la operación de E / S y puede procesar inmediatamente otro Cosa, este es un proceso sin bloqueo
En consecuencia, la E / S de Nginx no se bloquea y la E / S de Apache se bloquea
Permítanme hablar brevemente sobre mis puntos de vista.
Sin bloqueo siempre funciona con asíncrono (Nginx), y el bloqueo siempre funciona con sincrónico (Apache).
Debido a que Nginx se comunica de forma asíncrona, su E / S sin bloqueo es significativa (porque asíncrono puede manejar múltiples solicitudes al mismo tiempo, cuando se realiza una operación de E / S solicitada, el proceso de trabajo puede procesar otras solicitudes )
Debido a que Apache se comunica sincrónicamente, su E / S sin bloqueo no tiene sentido (debido a la sincronización, un proceso solo puede procesar una solicitud web, y cuando se realiza la operación de E / S solicitada, el proceso no tiene otras solicitudes. Puede manejar)
Bien, después de hablar sobre los conceptos de bloqueo y no bloqueo, pasemos a nuestro modelo basado en eventos de actualidad.
Después de solicitar una operación de E / S, ¿cómo podemos saber que la solicitud de E / S se ha completado y obtener el resultado de la E / S? ¡Hay dos ideas!
Primero, el proceso de trabajo marca las operaciones de E / S, y luego sondea periódicamente estas marcas. Si la operación de E / S sondeada se ha completado, nuestro proceso procesará las E / S, de lo contrario no se procesará.
En segundo lugar, el proceso de trabajo ya no pregunta activamente, pero después de que se completa la operación de E / S, de alguna manera, el núcleo informa al proceso que la operación de E / S se ha completado, y luego el proceso de trabajo procesa la operación de E / S.
Obviamente, la eficiencia del segundo método será mayor, ya que atravesar todas las operaciones de E / S sin duda desperdiciará recursos del sistema, especialmente cuando la cantidad de concurrencia es grande y hay muchas operaciones de E / S. Es muy grande, entonces la respuesta a las solicitudes de los usuarios será lenta, es decir, el rendimiento disminuirá
Volviendo a nuestro Nginx y Apache, Apache usa el primer modelo, el representante típico se llama modelo selecto, y Nginx usa el segundo modelo, la implementación en Linnux es el modelo epoll
A continuación, presentamos brevemente algunos modelos selectos y epoll
select library
Los pasos para usar select library son:
primero, crear un conjunto de descriptores para el evento de interés (archivo específico para operaciones de E / S). Para un descriptor, puede prestar atención al evento de lectura (lectura), evento de escritura (escritura) y evento de excepción (Excepción), por lo que debe crear tres tipos de conjuntos de descriptores de eventos, que se utilizan para recopilar descriptores de eventos de lectura El descriptor del evento y el descriptor del evento anormal
llaman a la función subyacente select () y esperan a que ocurra el evento. Luego sondee cada descriptor de eventos de todas las colecciones de descriptores de eventos, verifique si hay un evento correspondiente y procese si hay
Cree un conjunto de descriptores para cada solicitud de E / S, que contiene tres tipos, y luego recorra estos conjuntos regularmente, y devuelva el resultado de la llamada al proceso del proceso de trabajo una vez que se complete la E / S
biblioteca epoll La biblioteca
epoll es una de las bibliotecas de alto rendimiento impulsadas por eventos compatibles con el servidor Nginx. La eficiencia de la biblioteca epoll es muy alta
La biblioteca de selección y la biblioteca de polo se procesan creando una lista de eventos pendientes y luego enviando esta lista al kernel. Al regresar, verifique la lista sondeando para determinar si ha ocurrido un evento. De esta manera, cuando hay muchos descriptores, la eficiencia se vuelve muy baja .
Una mejor práctica es dejar la gestión de la lista de descriptores en el núcleo. Una vez que sucede algo, el núcleo notifica el proceso de la lista de descriptores del evento, lo que evita sondear toda la lista de descriptores. Epoll La biblioteca es un modelo
Primero, la biblioteca epoll informa al núcleo para crear una lista de eventos con descriptores de N a través de llamadas relacionadas. Luego, configure los eventos de interés para estos descriptores y agréguelos a la lista de eventos del núcleo. En el proceso de codificación específico, También puede modificar y eliminar los descriptores en la lista de eventos a través de llamadas relacionadas
Una vez completada la configuración, la biblioteca de epoll comienza a esperar a que el núcleo notifique que se ha producido un evento. Después de que se produce un evento, el núcleo informa la lista de descriptores del evento a la biblioteca de epoll. Obtenga la biblioteca epoll de la lista de eventos, y puede procesar el evento
La biblioteca epoll es eficiente en la plataforma Linux. Admite un proceso para abrir una gran cantidad de descriptores de eventos. El límite superior es la cantidad máxima de archivos que el sistema puede abrir. Al mismo tiempo, la eficiencia de E / S de la biblioteca epoll no disminuye linealmente con el aumento en el número de descriptores. Solo funcionará en los descriptores "activos" informados por el núcleo
A través del análisis del modelo de procesamiento de eventos, podemos descubrir por qué el rendimiento de Nginx es mejor que el de Apache
porque el modelo epoll utilizado por Nginx es más eficiente cuando se procesan solicitudes, especialmente en entornos de alta concurrencia. Debido a que el modelo seleccionado de Apache necesita atravesar descriptores de archivos, cuando la concurrencia es grande, el tiempo y el consumo de recorrido son relativamente grandes, lo que causará pérdida de rendimiento, y el modelo de epoll es diferente. En el caso de alta concurrencia, todavía es causado por El kernel notifica al proceso de trabajo la finalización de E / S, y no pasa por él. Solo informa al proceso de trabajo cuando se completa, por lo que el rendimiento de nginx bajo alta concurrencia no tendrá mucho impacto, y Apache está bajo alta concurrencia. El rendimiento se reducirá considerablemente
