httpd modo de funcionamiento del MPM
MPM (Multi -Procesamiento Módulos) multiprocesamiento módulo de modo de
prefork: multi-proceso modelo de I / O, cada proceso en respuesta a una solicitud, el modelo por defecto
modo de Pre-derivado, un proceso de control maestro y, a continuación genera una pluralidad de sub-procesos, cada sub-proceso tiene un hilo independiente en respuesta a una solicitud del usuario, la memoria ocupada por relativamente, pero es relativamente estable, que puede ser un número mínimo y máximo de procesos, la más antigua un modelo, es también el modo más estable para el tráfico no es una gran escena
características:
- Un proceso principal: el reciclaje y la generación de n sub-proceso, crea un socket, no responde a la solicitud
- Una pluralidad de sub-procesos: procesos de trabajo de trabajo, cada proceso hijo un proceso de petición, el sistema inicial, el proceso generado por adelantado una pluralidad de reposo, a la espera de una petición, el máximo no excede de 1024
Beneficios: establo
Desventajas: lento, intensivos en recursos, no es adecuado para escenarios de alta concurrencia
trabajador: multiplexados multi-proceso I / O modelo, multi-hilo multi-proceso, IIS utiliza este modelo
Es un multi-proceso y el modelo híbrido multiproceso, hay un proceso de control para iniciar múltiples sub-procesos, cada proceso hijo que contiene un hilo fijo, utilizar el hilo para manejar el proceso de solicitud, cuando el hilo no se utiliza pondrá en marcha una nueva el proceso hijo y, a continuación, comenzar a procesar el hilo solicitud dentro del proceso, debido a su uso de enhebrar solicitud, que puede soportar mayor concurrencia.
características:
Un proceso principal: generar procesos hijo m, cada proceso es responsable del nacimiento de un niño n hilos, cada hilo en respuesta a una solicitud, y transmite una petición de respuesta:
mxn
Ventajas: En comparación prefork menos ocupado de memoria, pueden manejar más solicitudes de forma simultánea
Desventajas: keep-alive servicios de larga, y siempre será ocupada por un hilo, incluso si no hay transmisión de datos, también tienen que esperar hasta que no se dará a conocer el tiempo de espera. Si hay demasiados hilos, están tan ocupados, que puede conducir a ningún hilos de servicio en escenarios de alta concurrencia disponibles. (El problema en el modo prefork, lo mismo sucederá)
evento: evento basado en modelos (variantes de modelos trabajador)
Apache en los últimos modelos, son modelo orientado a eventos (epoll), cada proceso en respuesta a varias peticiones, ahora tiene una versión estable modos disponibles. Es muy parecido al patrón y el trabajador, la mayor diferencia es que resuelve el siguiente escenario de mantenimiento de conexión, los residuos de las cuestiones de recursos durante mucho tiempo han sido ocupada por un hilo (porque algunos hilos son de mantenimiento de conexión, colgando en el aire, donde la espera, poco solicitud de media más, incluso esperar un tiempo de espera). MPM caso, habrá un hilo dedicado para gestionar el tipo de mantenimiento de conexión de hilo, cuando hay una petición real a través de la solicitud a la hebra del servidor, después de la aplicación, sino también permitir que sea puesto en libertad. Esto mejora la capacidad de procesamiento de solicitudes en escenarios de alta concurrencia
evento sólo cuando hay transmisión de datos comenzó a establecer una conexión, la solicitud de conexión dará lugar a un subproceso de trabajo, que utiliza una opción TCP, llamado el retraso de aceptar conexiones TCP_DEFER_ACCEPT, añadir esta opción, sólo si la conexión TCP cliente, no envíe la solicitud, no se disparará Aceptar la operación, no se disparará al trabajador otro trabajo, un simple anti-ataque (conexión TCP
características:
Un proceso principal: generar procesos m niño, cada proceso es responsable del nacimiento de un niño n hilos, cada hilo en respuesta a una solicitud, y transmite la respuesta de solicitud: m * n, un subproceso de supervisión dedicada a gestionar el tipo de mantenimiento de conexión de hilo, cuando hay una petición real, la petición se pasa al subproceso de servicio, después de la aplicación, sino que también permitió la liberación. Esto mejora la capacidad de procesamiento de solicitudes en escenarios de alta concurrencia
Ventajas: responden un único subproceso a múltiples peticiones, ocupa menos memoria, alta concurrencia en virtud de un mejor rendimiento, habrá un hilo dedicado para gestionar el tipo de mantenimiento de conexión de hilo, cuando hay una solicitud para convertirse en realidad, y pasa la petición a la hebra del servidor después de terminado, y permitir que se libere
Contras: no hay control de thread-safe
Hay peticiones reales a lo largo del tiempo, se pasa la petición al servidor de la rosca, después de la aplicación, sino que también permite que se libere
Contras: no hay control de thread-safe
