Modo de evento MPM (módulo de procesamiento múltiple)
serverlimit 50 indica el número máximo de procesos que el servidor puede abrir
startservers proceso de inicio inicial 3
minparethreads proceso inactivo mínimo 5
maxsparethreads proceso inactivo máximo 10
Apache debe asegurarse de que haya una cierta cantidad de procesos de búfer inactivos para dejar una pared trasera para su carga de acceso. Al principio, el acceso está ocupado por 2 procesos (proceso inicial), luego el proceso inactivo es 1, por si acaso alguien más Tengo una pared trasera para acceder. Apache estipula que el proceso inactivo mínimo es 5. Luego, el proceso principal de apche (el proceso principal creado por el usuario raíz) aumenta en 1 proceso en el primer segundo (el proceso inactivo también se denomina creación de usuario del demonio de proceso secundario) y el segundo Los segundos aumentarán la cantidad de procesos en 2 y el tercer segundo aumentará la cantidad de procesos en 4, hasta que se asegure de que su proceso inactivo sea mayor que los minutos especificados para los subprocesos5, puede detener el aumento. Este es un proceso dinámico. A medida que aumenta el número de visitas, el número de procesos Habrá más y más reuniones, hasta que muchas personas de repente se desconecten y la marea retroceda, entonces supongamos que finalmente comencé 100 procesos y retiré 20 procesos, luego en ese momento el límite de 20 procesos, de hecho, satisfecho Es mayor que el número mínimo de procesos inactivos, pero en caso de que 100 se retire por completo, son 100 procesos inactivos, por lo que hay un proceso inactivo máximo, más que el proceso inactivo máximo, cerraré, de todos modos, el proceso inactivo, apache calculará el intervalo de la pared posterior de todos modos Debe controlarse entre el proceso inactivo mínimo y el proceso inactivo máximo.
La forma más típica del modo de trabajo de eventos es envolver varios subprocesos en el proceso, el valor predeterminado es 25, el código real es el subproceso, por lo que el modo de trabajo de eventos es adecuado para manejar la alta carga y alta concurrencia de Apache, y hay otra característica del evento que se resuelve Problema de congestión asincrónica sin alquiler, qué significa, es que muchas personas están conectadas a esta página web, pero esperan sin solicitar nada, y mantienen vivo que keepalive mantiene la conexión hasta el timeout keepalive, lo que dará lugar a recursos. Desperdicio, el modo de trabajo de eventos es para resolver este problema, cada proceso tiene un hilo de keepalive para tratar, para lidiar con el keepalive de mi cliente en este proceso está pendiente **** entonces me ocuparé de usted, si accede al mouse haga clic en una pequeña solicitud , Luego, el hilo normal de al lado en el mismo proceso responsable del procesamiento de solicitudes lo procesará. Si hace clic durante un período de tiempo y ya no hace clic, entonces debe volver al hilo keepalive, y un hilo responsable de procesar las solicitudes se conectará a un cliente
maxrequestworkers permite que el servidor responda a la cantidad de subprocesos al mismo tiempo al mismo tiempo. Un subproceso corresponde a un cliente. Si el número de solicitudes excede el número de solicitudes, se pondrá en cola. Por ejemplo, Apache ejecuta 20 procesos y cada proceso ejecuta 24 subprocesos de servicio. El servidor puede realizar 24 * 20 al mismo tiempo. = 480 solicitudes http simultáneas, las primeras 480 están en línea, usted es el 481, es posible que deba hacer cola, entonces, ¿por qué hace cola en Double Eleven, debido a que los subprocesos de su servidor son tantos, siempre hay un límite superior para las solicitudes? , Su velocidad de Internet no es buena, tiene que hacer cola si entra lentamente, por lo que la mejor solución es tener una velocidad de Internet rápida y el ancho de banda del cable de red sea lo suficientemente alto. Use la computadora para agarrarlo, manténgalo encendido, no se preocupe por la falla del servidor,
maxconnnectionperchild cada proceso secundario en su ciclo de vida El número total máximo de solicitudes http que se pueden procesar dentro, establecido en 0 significa que el proceso nunca se detendrá. No hay límite superior para las solicitudes http, que consumirán recursos de memoria. El término se denomina pérdida de memoria php. Generalmente hay un límite superior, como el número total. 20000 ha terminado y un proceso se reinicia cuando llega
Ventajas del modo de evento : multiproceso, siempre hay procesos inactivos, múltiples subprocesos en el proceso, hay subprocesos en el proceso para manejar solicitudes http y hay subprocesos especiales para lidiar con el problema de los clientes keepalive que ocupan recursos sin acceso, lo cual se puede lograr y el cliente no hace clic y Haga clic en asincrónico y sin bloqueo. Es adecuado para una alta navegación simultánea y este modo está habilitado. Hay pocos procesos. ¿Hay subprocesos en el proceso? Por lo tanto, el uso de memoria será menor.
Condiciones del modo de evento:
se requiere compatibilidad con el sistema operativo Linux Ambas versiones, epoll y 2.6 de Linux son compatibles. No será compatible cuando sean antiguas.
En segundo lugar, el módulo incorporado oficial es compatible con apache en modo evento. Si es un módulo de terceros, es posible que deba considerarlo. Apache en modo evento puede que no Soporte
y luego conexión https. Un hilo corresponde a una solicitud. ¿Es la conexión segura? Si se procesa la conexión https, volverá al modo trabajador. No hay un hilo keepalive especial para administrar los clientes que no hacen clic para acceder.
modelo de trabajador modelo de
trabajador es una versión mejorada del modo de evento, excepto que el proceso no es subprocesos secundarios específicos para manejar keepalive para mantener la conexión, un subproceso completamente a tope a un cliente, no puede resolver el problema, los recursos de conexión largos están ocupados, el servicio no se puede lograr No hay diferencia entre los hilos y mantiene los hilos asíncronos y sin bloqueo.
Desventajas de event y worker: pero worker y event también son imperfectos. Si un hilo falla, todo el proceso "morirá" junto con cualquiera de sus hilos. Debido a que los hilos comparten espacio de memoria, un programa debe ser El sistema reconoce que cada hilo es seguro; de lo contrario, es fácil hacer que varios clientes interrumpan la conexión, lo que provocará que el servicio se bloquee y muchos modos de eventos del módulo php no son compatibles.
modo prefork el modo
prefork utiliza varios procesos secundarios y solo hay un subproceso en un proceso. En la mayoría de las plataformas, el modo prefork es más eficiente, seguro y maduro que los modos de trabajador y evento, porque un bloqueo del proceso no afectará a otros subprocesos ni a otras solicitudes del cliente , ¿Y es un proceso que maneja un subproceso, acoplamiento dedicado, eficiente y rápido, no es necesario compartir memoria entre subprocesos, por lo que hay una administración de memoria física especial, la memoria es grande, no rápida? En segundo lugar, no hay necesidad de preocuparse por la compatibilidad de subprocesos de módulos de terceros El problema es que apache no puede reconocer módulos de terceros en el modo de trabajo de eventos y volverá al modo de trabajo, por lo que el modo de prefork para algunos sitios web pequeños y medianos es más maduro, estable, eficiente y rápido.
Resumen: Por ejemplo, si necesita una mejor escalabilidad, puede elegir trabajador O MPM con subprocesos de eventos, y necesita una mejor estabilidad y compatibilidad para adaptarse a algún software antiguo que puede usar prefork.
La prueba de configuración del modo de evento y el
código fuente de la prueba de esfuerzo ab compilar e instalar especifican el modo de trabajo cuando se ejecuta el script de configuración
Si cambia después de compilar, puede ver que el archivo de configuración de mpm tiene tres modos, pero parece difícil cambiar centos. El método de cambio de Redhat es el siguiente
Tomemos como ejemplo la configuración del modo evento: ¡el modo más estable de prefork es el mismo!
prueba de esfuerzo ab
Antes de que apache esté optimizado
Cabe señalar que este parámetro -n es equivalente a una solicitud tcp, que es equivalente a cuántos clientes se conectan al servidor a la vez, y este -c es equivalente a una solicitud concurrente de httpd, que es equivalente al número de solicitudes http emitidas por un cliente, por lo que El número final de solicitudes es n * c, que es una forma eficaz de probar la presión del rendimiento del servidor
A continuación, realicemos el ajuste. El proceso inicial aumenta, los procesos secundarios inactivos se expanden, la cantidad de subprocesos por proceso secundario aumenta y la cantidad de solicitudes http que cada proceso permite procesar aumenta. Echemos un vistazo al tiempo total de procesamiento del servidor de estas solicitudes. hora
Muchas de las herramientas de prueba de rendimiento de estrés que se utilizan en la vida real son de terceros, ocho o nueve tipos. En producción, el ab que viene con Apache se usa menos para las pruebas de estrés. Los de código abierto más conocidos son LoadRunner, Apache JMeter, etc.
Para una mejor comprensión de los enlaces específicos de prefork, trabajador y evento son los siguientes:
https://blog.51cto.com/13043516/2342574