{"id":20730,"date":"2026-08-17T11:52:23","date_gmt":"2026-08-17T09:52:23","guid":{"rendered":"https:\/\/webhosting.de\/apache-event-mpm-vs-worker-mpm-webserver-tuning-optimierung\/"},"modified":"2026-08-17T11:52:23","modified_gmt":"2026-08-17T09:52:23","slug":"mpm-event-de-apache-frente-a-mpm-worker-ajuste-y-optimizacion-del-servidor-web","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/apache-event-mpm-vs-worker-mpm-webserver-tuning-optimierung\/","title":{"rendered":"MPM Event de Apache frente a MPM Worker: un \u00abturbo\u00bb moderno para servidores web con cargas elevadas"},"content":{"rendered":"<p>Voy a explicar en dos frases por qu\u00e9 la elecci\u00f3n del <strong>MPM de Apache<\/strong> influye de forma apreciable en el rendimiento, la latencia y la estabilidad bajo una carga elevada. Para ello, comparo concretamente Event MPM y Worker MPM en el caso de conexiones \u00abkeep-alive\u00bb prolongadas, HTTP\/2 y un alto grado de paralelismo, y a partir de ah\u00ed deduzco recomendaciones claras para el ajuste del sistema.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<p>Para que captes de inmediato las ideas m\u00e1s importantes, resumir\u00e9 brevemente los puntos clave y resaltar\u00e9 en negrita las palabras clave decisivas. A partir de estos puntos, m\u00e1s adelante derivar\u00e9 pasos concretos y configuraciones, que explicar\u00e9 de forma pr\u00e1ctica. Eval\u00fao ambos MPM de forma sistem\u00e1tica con perfiles de carga realistas y numerosas conexiones. As\u00ed podr\u00e1s ver de un vistazo qu\u00e9 m\u00f3dulo destaca en tu pila. La lista te ofrece un atajo para tomar decisiones bien fundamentadas en el d\u00eda a d\u00eda.<\/p>\n<ul>\n  <li><strong>Evento<\/strong> Desvincula Idle-Keep-Alive de los hilos de solicitud y se adapta a un gran n\u00famero de conexiones.<\/li>\n  <li><strong>Trabajador<\/strong> Da buenos resultados con solicitudes cortas, pero consume subprocesos cuando el \u00abkeep-alive\u00bb es prolongado.<\/li>\n  <li><strong>HTTP\/2<\/strong> se beneficia de forma cuantificable del evento gracias a una gesti\u00f3n eficiente del multiplexado.<\/li>\n  <li><strong>Recursos<\/strong>: Esta funci\u00f3n mantiene un menor consumo de RAM y CPU por cada solicitud activa.<\/li>\n  <li><strong>Compatibilidad<\/strong>: Es obligatorio utilizar m\u00f3dulos seguros para subprocesos; mod_php sigue siendo un entorno Prefork.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/serverraum-webserverturbo-4837.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Por qu\u00e9 Worker y Event se llevan la palma<\/h2>\n\n<p>En una empresa moderna, apuesto claramente por <strong>Hilos<\/strong>, ya que ocupan menos RAM por conexi\u00f3n que los procesos. Anteriormente, Prefork ofrec\u00eda seguridad con m\u00f3dulos no seguros para subprocesos, pero resulta dif\u00edcil de escalar cuando hay muchas conexiones. Hoy en d\u00eda predominan los modelos \u00abWorker\u00bb y \u00abEvent\u00bb, ya que gestionan de forma eficaz un gran n\u00famero de usuarios simult\u00e1neos. Esto resulta especialmente ventajoso con Keep-Alive activo y HTTP\/2, donde las conexiones permanecen abiertas durante mucho tiempo. Es precisamente ah\u00ed donde se pone de manifiesto <strong>Evento<\/strong> sus puntos fuertes, ya que no ocupa valiosos hilos de solicitud con conexiones inactivas.<\/p>\n\n<h2>MPM Apache Worker: arquitectura y limitaciones<\/h2>\n\n<p>Defino los \u00abworkers\u00bb como un h\u00edbrido entre procesos y <strong>Hilos<\/strong>, en el que cada proceso hijo cuenta con un hilo de escucha y varios hilos de servidor. Una solicitud llega a un hilo, recibe una respuesta y, a continuaci\u00f3n, libera el hilo. Si la conexi\u00f3n permanece abierta, el mismo hilo permanece vinculado a ella. Esto provoca inactividad cuando muchos clientes esperan durante mucho tiempo o env\u00edan peque\u00f1as solicitudes de forma espor\u00e1dica. Por lo tanto, quien utilice Worker deber\u00eda dimensionar de forma consciente los grupos de hilos y los l\u00edmites; para ello, puede consultar mi breve <a href=\"https:\/\/webhosting.de\/es\/threadpool-optimizacion-del-servidor-workerhosting-threadpool\/\">Optimizaci\u00f3n del grupo de hilos<\/a> tomarlo como punto de partida.<\/p>\n\n<h2>MPM Event de Apache: explicaci\u00f3n del bucle de eventos<\/h2>\n\n<p>Describo un evento como un \u00abworker m\u00e1s bucle de eventos\u00bb, es decir, <strong>oyente<\/strong>-Hilos que dejan en espera las conexiones inactivas. El listener acepta nuevas conexiones, transfiere las solicitudes activas a hilos de trabajo libres y, a continuaci\u00f3n, recupera la conexi\u00f3n. De este modo, los hilos de solicitud solo trabajan cuando fluyen datos. Por lo tanto, pueden permanecer abiertos cientos o miles de clientes sin bloquear los hilos. Precisamente esto <strong>Aparcamiento<\/strong> es lo que hace que Event sea tan eficiente con cargas de trabajo t\u00edpicas de HTTP\/1.1 y HTTP\/2.<\/p>\n\n<h2>Evento frente a trabajador: diferencias bajo carga<\/h2>\n\n<p>Siempre eval\u00fao ambos MPM en condiciones reales <strong>Carga<\/strong> con tiempos de Keep-Alive prolongados. El worker alcanza r\u00e1pidamente el l\u00edmite, ya que las conexiones inactivas ocupan hilos que luego no est\u00e1n disponibles para nuevas solicitudes. Event mantiene libres los grupos de subprocesos y traslada las conexiones inactivas al bucle de eventos. De este modo, el n\u00famero de usuarios que se pueden atender simult\u00e1neamente aumenta considerablemente, mientras que las latencias se mantienen estables. Quien necesite informaci\u00f3n para tomar una decisi\u00f3n, lo mejor es que compare casos concretos <a href=\"https:\/\/webhosting.de\/es\/threading-modelo-de-servidor-alojamiento-basado-en-eventos-comparacion-serverperf\/\">Modelos de servidor basados en eventos<\/a> con grupos de subprocesos en pruebas de carga.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/ApacheWebserverMeeting2573.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compatibilidad: m\u00f3dulos y configuraciones habituales<\/h2>\n\n<p>Primero compruebo el <strong>M\u00f3dulos<\/strong>, ya que tanto Worker como Event requieren seguridad de subprocesos. Las pilas cl\u00e1sicas de mod_php no son adecuadas, por lo que Prefork sigue siendo la opci\u00f3n m\u00e1s sensata en este caso. Sin embargo, si PHP se ejecuta a trav\u00e9s de PHP-FPM o FastCGI, me decanto claramente por Event. Lo mismo se aplica a los proxies inversos hacia servidores de aplicaciones, microservicios o backends de Go\/Node. En este tipo de configuraciones, \u00abWorker\u00bb y, sobre todo, <strong>Evento<\/strong> su potencia sin renunciar a la compatibilidad.<\/p>\n\n<h2>Configuraci\u00f3n: las directivas m\u00e1s importantes<\/h2>\n\n<p>Te presento de forma concisa las directrices clave para que puedas situarlas correctamente y <strong>personalizado<\/strong>. MaxRequestWorkers limita el n\u00famero de solicitudes procesadas simult\u00e1neamente; en el caso de Event, a menudo se puede aumentar este valor, ya que las conexiones inactivas no bloquean el sistema. ThreadsPerChild define el n\u00famero de subprocesos por proceso; un valor demasiado bajo reduce el rendimiento, mientras que uno demasiado alto sobrecarga la CPU. ServerLimit establece el l\u00edmite de procesos y, por lo tanto, el l\u00edmite m\u00e1ximo de solicitudes paralelas en el conjunto. Con KeepAliveTimeout controlas cu\u00e1nto tiempo permanecen abiertas las conexiones; cuanto mayor sea el valor, mayor ser\u00e1 el beneficio <strong>Evento<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/webserver-turbo-mpm-comparison-8394.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comparaci\u00f3n en forma de tabla: \u00abWorker\u00bb frente a \u00abEvent\u00bb<\/h2>\n\n<p>Resumo las caracter\u00edsticas m\u00e1s importantes en un formato conciso <strong>Cuadro<\/strong> juntos, para que puedas ver las diferencias de inmediato. No sustituye a una prueba de carga, pero te ayuda a centrar la atenci\u00f3n en las caracter\u00edsticas fundamentales. Lee los puntos de izquierda a derecha y as\u00f3yalos a tu perfil de tr\u00e1fico. As\u00ed encontrar\u00e1s r\u00e1pidamente el MPM adecuado para tu arquitectura. La atenci\u00f3n se centra claramente en la escalabilidad, los requisitos de recursos y el comportamiento con <strong>Keep-Alive<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Criterio<\/th>\n      <th>Worker MPM<\/th>\n      <th>Evento MPM<\/th>\n      <th>repercusi\u00f3n<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Gesti\u00f3n de Keep-Alive<\/td>\n      <td>El hilo permanece vinculado a la conexi\u00f3n<\/td>\n      <td>El bucle de eventos deja en espera las conexiones inactivas<\/td>\n      <td>El evento mantiene libres los hilos de solicitud<\/td>\n    <\/tr>\n    <tr>\n      <td>Uso de recursos<\/td>\n      <td>M\u00e1s hilos atados en reposo<\/td>\n      <td>Menos hilos ocupados en estado de inactividad<\/td>\n      <td>Menor consumo de RAM y CPU por solicitud activa<\/td>\n    <\/tr>\n    <tr>\n      <td>Latencia bajo carga<\/td>\n      <td>Sal m\u00e1s temprano<\/td>\n      <td>Se mantiene estable durante m\u00e1s tiempo<\/td>\n      <td>Mejor respuesta<\/td>\n    <\/tr>\n    <tr>\n      <td>Compatibilidad con HTTP\/2<\/td>\n      <td>Ordenado<\/td>\n      <td>Muy eficiente<\/td>\n      <td>Ventajas del multiplexado<\/td>\n    <\/tr>\n    <tr>\n      <td>Configuraci\u00f3n<\/td>\n      <td>MaxRequestWorkers, ThreadsPerChild, ServerLimit<\/td>\n      <td>Igual, m\u00e1s la optimizaci\u00f3n del bucle de eventos<\/td>\n      <td>El evento permite una mayor ocupaci\u00f3n<\/td>\n    <\/tr>\n    <tr>\n      <td>Compatibilidad<\/td>\n      <td>Se necesitan m\u00f3dulos a prueba de subprocesos<\/td>\n      <td>Del mismo modo, preferiblemente con PHP-FPM<\/td>\n      <td>Prefork sigue siendo una opci\u00f3n de mod_php<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Pr\u00e1ctica: flujo de trabajo de puesta a punto y medici\u00f3n<\/h2>\n\n<p>Siempre empiezo partiendo de una base limpia <strong>Monitoreo<\/strong> y los datos de registro. A continuaci\u00f3n, voy variando gradualmente los valores de MaxRequestWorkers y ThreadsPerChild y mido la latencia, la tasa de errores y la carga de la CPU. Pruebo el KeepAliveTimeout por etapas, ya que el tiempo ideal depende en gran medida del comportamiento del cliente. A partir de aqu\u00ed, merece la pena comparar \u00abEvent\u00bb y \u00abWorker\u00bb con herramientas como ab, wrk o JMeter. Solo cuando las m\u00e9tricas se ven correctas, fijo el <strong>Perfiles<\/strong> y documenta los indicadores clave.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/apache_mpm_techoffice_4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cu\u00e1ndo sigue siendo recomendable utilizar Prefork<\/h2>\n\n<p>Recurro a Prefork cuando es imprescindible que el c\u00f3digo no sea seguro para subprocesos <strong>M\u00f3dulos<\/strong> deben ejecutarse. En ese caso, el aislamiento por proceso es m\u00e1s importante que la escalabilidad. A cambio, acepto un consumo de RAM considerablemente mayor por conexi\u00f3n. Para las aplicaciones heredadas que no se pueden adaptar, esta suele ser la opci\u00f3n m\u00e1s realista. Sin embargo, en cuanto utilizo PHP-FPM u otros servidores de aplicaciones externos, prefiero <strong>Evento<\/strong> de forma clara.<\/p>\n\n<h2>El contexto del alojamiento web y la elecci\u00f3n del proveedor<\/h2>\n\n<p>En el \u00e1mbito del alojamiento web, presto atenci\u00f3n a los perfiles MPM, ya que a menudo hay muchos hosts virtuales en una misma m\u00e1quina <strong>ejecute<\/strong>. Event ofrece aqu\u00ed el aprovechamiento m\u00e1s eficiente de los recursos, especialmente con HTTP\/2 y TLS. Si mi pila requiere PHP-FPM, configuro Event como opci\u00f3n predeterminada. Para contextualizar y comprobar los aspectos t\u00e9cnicos, resulta \u00fatil un breve <a href=\"https:\/\/webhosting.de\/es\/webserver-worker-models-prefork-worker-event-mpm-serverperf\/\">Comparaci\u00f3n entre Prefork, Worker y Event<\/a> antes de la elecci\u00f3n definitiva. Quien haga estos deberes obtendr\u00e1 resultados notablemente mejores <strong>Tiempos de respuesta<\/strong> por euro.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/entwickler_apachempm_9821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pacto de buenas pr\u00e1cticas<\/h2>\n\n<p>Lo utilizo sistem\u00e1ticamente <strong>PHP-FPM<\/strong> u otros servidores de aplicaciones externos, para que Event pueda desarrollar todo su potencial. A continuaci\u00f3n, ajusto los par\u00e1metros MaxRequestWorkers y ThreadsPerChild en funci\u00f3n de los n\u00facleos de la CPU y la RAM, y compruebo los l\u00edmites m\u00e1ximos del sistema. Cuando hay muchos clientes inactivos, elijo \u00abEvent\u00bb, aumento deliberadamente el valor de \u00abKeepAliveTimeout\u00bb y superviso las latencias. Para cargas de trabajo con peticiones muy breves y un \u00abKeep-Alive\u00bb moderado, basta con \u00abWorker\u00bb, siempre que los m\u00f3dulos sigan siendo seguros para subprocesos. Sin una supervisi\u00f3n continua de la carga de los subprocesos, los errores y <strong>Latencias<\/strong> No tomo ninguna decisi\u00f3n definitiva.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/serverraum-performance-4096.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ejemplos concretos de configuraci\u00f3n para Event y Worker<\/h2>\n<p>Proporciono dos perfiles minimalistas que utilizo como punto de partida y que luego perfecciono bas\u00e1ndome en los valores de medici\u00f3n. Es fundamental: <strong>MaxRequestWorkers = ServerLimit \u00d7 ThreadsPerChild<\/strong>. Hago un c\u00e1lculo a la inversa a partir del presupuesto de RAM y de las necesidades por hilo (incluidos m\u00f3dulos, TLS y b\u00faferes) y voy aumentando poco a poco.<\/p>\n<pre><code>Ejemplo #: Evento MPM (HTTP\/2, PHP-FPM)\nServerLimit 16\nThreadLimit 256\nThreadsPerChild 64\nMaxRequestWorkers     1024\nStartServers 4\nMaxConnectionsPerChild 10000\n\nKeepAlive On\nMaxKeepAliveRequests  100\nKeepAliveTimeout 15\n\n# Opcional y ajustar solo tras realizar mediciones:\n# ListenBacklog 1024\n# ThreadStackSize     1048576   # 1 MB, solo si los m\u00f3dulos lo permiten\n# AsyncRequestWorkerFactor 2    # Ajuste fino del bucle de eventos; normalmente se deja el valor por defecto\n\n# HTTP\/2\nProtocols h2 http\/1.1\n# H2MaxSessionStreams  100-200  # ajustar con precisi\u00f3n en funci\u00f3n de la capacidad del backend\n<\/code><\/pre>\n<pre><code>Ejemplo #: Worker MPM (solicitudes cortas, Keep-Alive moderado)\nServerLimit 8\nThreadLimit 256\nThreadsPerChild 50\nMaxRequestWorkers     400\nStartServers 4\nMaxConnectionsPerChild 5000\n\nKeepAlive On\nMaxKeepAliveRequests  100\nKeepAliveTimeout 3\nProtocols http\/1.1\n<\/code><\/pre>\n<p>Sostengo <strong>MaxConnectionsPerChild<\/strong> (Alias: MaxRequestsPerChild) distinto de 0, para detectar fugas ocultas. <strong>Tiempo de espera de KeepAlive<\/strong> Lo configuro deliberadamente m\u00e1s alto en \u00abEvent\u00bb, porque las conexiones inactivas son econ\u00f3micas; en \u00abWorker\u00bb lo mantengo bajo para no bloquear los hilos.<\/p>\n\n<h2>Ajuste fino de HTTP\/2 con Event<\/h2>\n<p>Tengo en cuenta en <strong>HTTP\/2<\/strong>, que los navegadores abren pocas conexiones y muchas <strong>Transmisiones<\/strong> multiplexar. De este modo, el cuello de botella pasa de estar en el n\u00famero de conexiones a estar en la asignaci\u00f3n equitativa de subprocesos y la capacidad del backend. Con \u00abEvent\u00bb, los subprocesos permanecen libres mientras un flujo est\u00e1 en espera; esto suaviza los picos de latencia. Herramientas pr\u00e1cticas:<\/p>\n<ul>\n  <li><strong>H2MaxSessionStreams<\/strong>: Normalmente me muevo en el rango de 50 a 200. Si es demasiado alto, se producen efectos de \u00abhead-of-line\u00bb en el backend; si es demasiado bajo, se desperdicia el paralelismo.<\/li>\n  <li><strong>MaxRequestWorkers<\/strong>: Con Event puedo aumentar el nivel, siempre que la RAM y la CPU lo soporten. Observo los percentiles 95 y 99 de latencia a medida que aumenta el paralelismo.<\/li>\n  <li><strong>TLS<\/strong>: Con ALPN y conjuntos de cifrado modernos reduzco los costes del handshake; adem\u00e1s, Event se beneficia porque las fases de inactividad entre r\u00e1fagas de streaming se gestionan de forma eficiente.<\/li>\n<\/ul>\n\n<h2>L\u00edmites del sistema operativo y colas de sockets<\/h2>\n<p>Antes de cada prueba de carga, compruebo los l\u00edmites del sistema; de lo contrario, no es el MPM el que impone las restricciones, sino el n\u00facleo. Para un n\u00famero elevado de conexiones, escalo especialmente:<\/p>\n<ul>\n  <li><strong>Descriptores de archivos<\/strong>: ulimit -n y systemd <code>LimitNOFILE<\/code> Lo aumento, por ejemplo, a 65536 o m\u00e1s; Apache necesita un FD por socket, log y pipe.<\/li>\n  <li><strong>atraso<\/strong>: <code>net.core.somaxconn<\/code> y <code>tcp_max_syn_backlog<\/code> Lo configuro adecuadamente (por ejemplo, 1024\u20134096) para que la cola de aceptaci\u00f3n no se desborde.<\/li>\n  <li><strong>Rango de puertos<\/strong> (en el caso de un proxy inverso): <code>rango_de_puertos_locales_ip<\/code> Aumento este valor (por ejemplo, de 10 000 a 65 000) cuando hay muchas conexiones salientes simult\u00e1neas con los servidores backend.<\/li>\n  <li><strong>FIN\/Tiempos muertos<\/strong>: Precauci\u00f3n con <code>tcp_fin_timeout<\/code>: si es demasiado agresivo, puede provocar cortes en la conexi\u00f3n; solo lo modifico utilizando la base de medici\u00f3n.<\/li>\n<\/ul>\n<p>Documento cada ajuste del n\u00facleo, junto con su justificaci\u00f3n, y lo verifico realizando una nueva medici\u00f3n de la carga. A falta de pruebas, la configuraci\u00f3n por defecto suele ser la correcta.<\/p>\n\n<h2>Supervisi\u00f3n y resoluci\u00f3n de problemas en el d\u00eda a d\u00eda<\/h2>\n<p>Activo <strong>Estado ampliado<\/strong> y utiliza \u00abserver-status\u00bb para comprobar el <strong>Marcador<\/strong>-Estados. En \u201eEvent\u00bb veo muchas conexiones inactivas o de mantenimiento de conexi\u00f3n, sin que los hilos de trabajo est\u00e9n al m\u00e1ximo de su capacidad. En el registro de errores aparece \u00abserver reached <strong>MaxRequestWorkers<\/strong> \u201csetting, consider raising the MaxRequestWorkers setting\u00bb, el servidor ya est\u00e1 al l\u00edmite; lo aumento con cautela y observo la RAM, la CPU y la tasa de errores.<\/p>\n<ul>\n  <li><strong>Campos de medici\u00f3n<\/strong>: En los registros de acceso recopilo los tiempos de respuesta (por ejemplo, %D\/%T), los c\u00f3digos de estado y los bytes; correlaciono los picos con la CPU y las E\/S.<\/li>\n  <li><strong>S\u00edntomas en Worker<\/strong>: Muchas conexiones \u00abkeep-alive\u00bb inactivas, hilos ocupados en 100 %, latencia creciente, 503\/504: indicio de hilos bloqueados.<\/li>\n  <li><strong>S\u00edntomas en un evento<\/strong>: Los hilos de escucha est\u00e1n muy cargados, pero los hilos de trabajo est\u00e1n libres; suele deberse a limitaciones de la red o del backend, no al MPM.<\/li>\n  <li><strong>Recarga suave<\/strong>: Aplico los cambios con <code>apachectl -k graceful<\/code> para que las conexiones existentes drenen correctamente.<\/li>\n<\/ul>\n\n<h2>Planificaci\u00f3n de la capacidad: de los n\u00facleos y la RAM a MaxRequestWorkers<\/h2>\n<p>Hago un c\u00e1lculo pragm\u00e1tico: \u00bfcu\u00e1nta RAM por hilo, m\u00e1s el b\u00fafer, quiero asignar? Teniendo en cuenta el TLS, los filtros y los m\u00f3dulos habituales, hago un c\u00e1lculo conservador de unos pocos MB por hilo. A continuaci\u00f3n, establezco <strong>MaxRequestWorkers<\/strong> de tal forma que la carga m\u00e1xima en los percentiles 95 y 99 se gestione sin necesidad de swap. A nivel de CPU, se aplica lo siguiente: los subprocesos que superan el n\u00famero de n\u00facleos solo son \u00fatiles siempre y cuando no requieran un tiempo de ejecuci\u00f3n elevado de forma constante. Con Event me atrevo a utilizar valores m\u00e1s altos, ya que las fases de inactividad apenas suponen un coste.<\/p>\n<ul>\n  <li><strong>Reglas generales<\/strong>: Inicio con 32-64 subprocesos por proceso, 4-16 procesos; a continuaci\u00f3n, medici\u00f3n y ajuste.<\/li>\n  <li><strong>ThreadStackSize<\/strong>: Si la memoria RAM es escasa y los m\u00f3dulos lo permiten, reduzco el tama\u00f1o de la pila (con precauci\u00f3n, realizando una prueba de estr\u00e9s).<\/li>\n  <li><strong>MaxKeepAliveRequests<\/strong>: Normalmente mantengo el valor por defecto; en el caso de los clientes \u00abchatty\u00bb, un valor m\u00e1s alto puede reducir la sobrecarga.<\/li>\n<\/ul>\n\n<h2>Escenarios de proxy inverso y conexiones con el backend<\/h2>\n<p>Me gusta especialmente utilizar Event en los backends de las aplicaciones porque <strong>Conectores frontales<\/strong> se almacena de forma eficiente, mientras que el trabajo propiamente dicho se lleva a cabo en el backend. Lo decisivo es entonces la agrupaci\u00f3n de los <strong>Conexiones de backend<\/strong> (mod_proxy):<\/p>\n<ul>\n  <li><strong>Keep-Alive con el backend<\/strong>: Se deja activo para ahorrar handshakes; tama\u00f1o de los pools (<em>m\u00e1x.<\/em> (por destino) en funci\u00f3n de la capacidad del backend.<\/li>\n  <li><strong>Tiempos de espera del proxy<\/strong>: Definir claramente los tiempos de espera para que los backends bloqueados no ocupen los subprocesos del frontend.<\/li>\n  <li><strong>HTTP\/2 hacia el backend<\/strong>: Siempre que puedo, utilizo H2 (por ejemplo, h2c internamente) para reducir el n\u00famero de conexiones y aumentar el n\u00famero de flujos; Event se adapta bien a ello.<\/li>\n<\/ul>\n<p>Analizo espec\u00edficamente los tiempos de latencia del frontend frente al backend; si solo aumenta el tiempo del backend, el ajuste del MPM por s\u00ed solo no basta: en ese caso, tengo que ajustar los tama\u00f1os de los pools, los tiempos de espera o los recursos del backend.<\/p>\n\n<h2>Estrategia de implementaci\u00f3n y migraci\u00f3n de \u00abWorker\u00bb a \u00abEvent\u00bb<\/h2>\n<p>Realizo la migraci\u00f3n siguiendo unos pasos claros: primero compruebo la <strong>Lista de m\u00f3dulos<\/strong> (apachectl -M) para comprobar la seguridad de subprocesos. Todo lo que no sea seguro para subprocesos (como el cl\u00e1sico mod_php) debe eliminarse o aislarse. A continuaci\u00f3n, activo Event, establezco valores iniciales conservadores y ejecuto pruebas de carga en el entorno de staging. En la implementaci\u00f3n, empiezo con una parte del tr\u00e1fico (Canary), comparo las m\u00e9tricas y solo entonces procedo a una implementaci\u00f3n a gran escala.<\/p>\n<ul>\n  <li><strong>comandos<\/strong>: Como es habitual en esta distribuci\u00f3n, desactivar y activar los m\u00f3dulos MPM (por ejemplo, a2dismod\/a2enmod) y reiniciar correctamente el sistema.<\/li>\n  <li><strong>Plan de contingencia<\/strong>: Tengo preparado un perfil de trabajador por si alg\u00fan m\u00f3dulo del evento se comportara de forma an\u00f3mala.<\/li>\n  <li><strong>Documentaci\u00f3n<\/strong>: Documento cualquier cambio en los l\u00edmites, los par\u00e1metros HTTP\/2 y los valores del n\u00facleo mediante mediciones \u00abantes y despu\u00e9s\u00bb.<\/li>\n<\/ul>\n\n<h2>La seguridad y el rendimiento de TLS, en el punto de mira<\/h2>\n<p>En lo que respecta al TLS, tengo en cuenta que los handshakes consumen muchos recursos de la CPU y pueden aumentar la latencia bajo carga. Con <strong>Reanudaci\u00f3n de la sesi\u00f3n<\/strong> Y, gracias a la selecci\u00f3n de algoritmos de cifrado modernos, reduzco los costes, al tiempo que gestiono de forma eficiente los periodos de inactividad. En combinaci\u00f3n con HTTP\/2 y ALPN, evito idas y vueltas adicionales. Importante: los b\u00faferes de TLS y los par\u00e1metros de OpenSSL forman parte de la huella de RAM por hilo; los tengo en cuenta en la planificaci\u00f3n de la capacidad.<\/p>\n\n<h2>Tolerancia a los errores y degradaci\u00f3n gradual<\/h2>\n<p>Estoy planificando para situaciones de sobrecarga: \u00bfest\u00e1 saturada la CPU o alcanza Apache <strong>MaxRequestWorkers<\/strong>, no quiero una avalancha de reintentos. Establezco tiempos de espera claros, p\u00e1ginas de error informativas y l\u00edmites de frecuencia en los proxies intermedios. Con Event, se mantienen m\u00e1s bajo presi\u00f3n <strong>Hilos<\/strong> libres para el trabajo real, mientras que las conexiones inactivas se dejan en espera; es precisamente esta reserva la que permite que el sistema siga funcionando durante m\u00e1s tiempo, hasta que la carga vuelva a disminuir o se active el escalado autom\u00e1tico.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>En mi trabajo diario apuesto por <strong>Evento<\/strong>, siempre que mi pila utilice m\u00f3dulos seguros para subprocesos y PHP-FPM. Este enfoque reduce los subprocesos ocupados en las conexiones inactivas, mantiene estable el tiempo de respuesta y aumenta el n\u00famero de usuarios atendidos en paralelo. Worker sigue siendo una opci\u00f3n s\u00f3lida para solicitudes cortas con un \u00abkeep-alive\u00bb moderado, cuando Event no resulta adecuado por motivos organizativos. Reservo Prefork para configuraciones con m\u00f3dulos no seguros para subprocesos o c\u00f3digo antiguo. Con pruebas de carga claras, un ajuste minucioso de las directivas y un <strong>Monitoreo<\/strong> Consigo que Apache alcance la velocidad m\u00e1xima de forma reproducible.<\/p>","protected":false},"excerpt":{"rendered":"<p>MPM Event de Apache frente a MPM Worker: descubre qu\u00e9 MPM ofrece el mejor rendimiento para la optimizaci\u00f3n moderna de servidores web y cu\u00e1ndo deber\u00edas optar por el m\u00f3dulo Event.<\/p>","protected":false},"author":1,"featured_media":20723,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20730","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"96","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Apache MPM","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20723","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20730","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=20730"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20730\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20723"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20730"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20730"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20730"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}