{"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-do-apache-vs-mpm-worker-ajuste-e-otimizacao-do-servidor-web","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/apache-event-mpm-vs-worker-mpm-webserver-tuning-optimierung\/","title":{"rendered":"MPM Event do Apache vs MPM Worker: um \u00abturbo\u00bb moderno para servidores web com cargas elevadas"},"content":{"rendered":"<p>Vou explicar, em duas frases, por que raz\u00e3o a escolha do <strong>Apache MPM<\/strong> influencia visivelmente o d\u00e9bito, a lat\u00eancia e a estabilidade sob carga elevada. Para tal, comparo concretamente o Event MPM e o Worker MPM no que diz respeito a liga\u00e7\u00f5es Keep-Alive prolongadas, HTTP\/2 e elevado paralelismo, e deduzo da\u00ed recomenda\u00e7\u00f5es claras de otimiza\u00e7\u00e3o.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<p>Para que possas compreender imediatamente as ideias mais importantes, vou resumir brevemente os pontos-chave e destacar as palavras-chave decisivas a negrito. A partir destes pontos, deduzo mais abaixo passos pr\u00e1ticos e configura\u00e7\u00f5es, que explico de forma pr\u00e1tica. Avalio ambos os MPMs de forma consistente, utilizando perfis de carga realistas com muitas liga\u00e7\u00f5es. Assim, poder\u00e1s perceber rapidamente qual o m\u00f3dulo que se destaca na tua pilha. A lista fornece um atalho para decis\u00f5es fundamentadas no funcionamento di\u00e1rio.<\/p>\n<ul>\n  <li><strong>Evento<\/strong> Desacopla o Idle-Keep-Alive dos threads de pedidos e adapta-se a um grande n\u00famero de liga\u00e7\u00f5es.<\/li>\n  <li><strong>Trabalhador<\/strong> Destaca-se em pedidos curtos, mas consome threads em casos de Keep-Alive prolongado.<\/li>\n  <li><strong>HTTP\/2<\/strong> beneficia-se de forma mensur\u00e1vel do Event gra\u00e7as a um tratamento eficiente do multiplexing.<\/li>\n  <li><strong>Recursos<\/strong>: O evento mant\u00e9m os consumos de RAM e CPU por pedido ativo mais baixos.<\/li>\n  <li><strong>Compatibilidade<\/strong>: Os m\u00f3dulos seguros para threads s\u00e3o obrigat\u00f3rios; o mod_php continua a ser um ambiente 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 que \u00e9 que o Worker e o Event est\u00e3o na frente<\/h2>\n\n<p>Numa empresa moderna, aposto claramente em <strong>T\u00f3picos<\/strong>, porque ocupam menos RAM por liga\u00e7\u00e3o do que os processos. O Prefork oferecia anteriormente seguran\u00e7a com m\u00f3dulos n\u00e3o seguros para threads, mas tem dificuldade em escalar quando h\u00e1 muitas liga\u00e7\u00f5es. Atualmente, os modelos \u00abWorker\u00bb e \u00abEvent\u00bb dominam, pois gerem de forma eficiente um grande n\u00famero de utilizadores simult\u00e2neos. Isto compensa especialmente com o Keep-Alive ativo e o HTTP\/2, onde as liga\u00e7\u00f5es permanecem abertas durante muito tempo. \u00c9 precisamente a\u00ed que se verifica <strong>Evento<\/strong> os seus pontos fortes, uma vez que n\u00e3o ocupa threads de pedidos importantes com liga\u00e7\u00f5es inativas.<\/p>\n\n<h2>MPM Apache Worker: arquitetura e limita\u00e7\u00f5es<\/h2>\n\n<p>Defino os \u00abworkers\u00bb como um h\u00edbrido entre processos e <strong>T\u00f3picos<\/strong>, em que cada processo filho possui um thread de escuta e v\u00e1rios threads de servidor. Um pedido \u00e9 encaminhado para um thread, \u00e9 respondido e, em seguida, o thread \u00e9 libertado. Se a liga\u00e7\u00e3o permanecer aberta, a mesma thread permanece ligada a essa liga\u00e7\u00e3o. Isto causa inatividade quando muitos clientes esperam durante muito tempo ou enviam apenas pequenas solicita\u00e7\u00f5es espor\u00e1dicas. Quem utiliza o Worker deve, por isso, dimensionar conscientemente os conjuntos de threads e os limites e pode consultar o meu breve <a href=\"https:\/\/webhosting.de\/pt\/thread-pool-otimizacao-do-servidor-workerhosting-threadpool\/\">Otimiza\u00e7\u00e3o do pool de threads<\/a> utilizar como ponto de partida.<\/p>\n\n<h2>MPM Event do Apache: explica\u00e7\u00e3o do ciclo de eventos<\/h2>\n\n<p>Descrevo o Event como um \u00abWorker mais Event Loop\u00bb, ou seja, <strong>Ouvinte<\/strong>-Threads que colocam as liga\u00e7\u00f5es inativas em espera. O \u00ablistener\u00bb aceita novas liga\u00e7\u00f5es, encaminha os pedidos ativos para threads de trabalho livres e, em seguida, recupera a liga\u00e7\u00e3o. Desta forma, as threads de pedido s\u00f3 funcionam quando h\u00e1 fluxo de dados. Centenas ou milhares de clientes podem, por isso, permanecer abertos sem bloquear as threads. \u00c9 precisamente isto que <strong>Estacionamento<\/strong> \u00e9 o que torna o Event t\u00e3o eficiente em cargas de trabalho t\u00edpicas do HTTP\/1.1 e do HTTP\/2.<\/p>\n\n<h2>Evento vs. Trabalhador: diferen\u00e7as sob carga<\/h2>\n\n<p>Avalio sempre ambos os MPMs em condi\u00e7\u00f5es reais <strong>Carga<\/strong> com tempos de Keep-Alive prolongados. O Worker atinge rapidamente o limite, porque as liga\u00e7\u00f5es inativas ocupam threads que, por sua vez, deixam de estar dispon\u00edveis para novos pedidos. O Event mant\u00e9m os conjuntos de threads livres e encaminha as liga\u00e7\u00f5es inativas para o ciclo de eventos. Desta forma, o n\u00famero de utilizadores que podem ser atendidos simultaneamente aumenta significativamente, enquanto as lat\u00eancias se mant\u00eam est\u00e1veis. Quem precisar de bases para a tomada de decis\u00f5es deve, de prefer\u00eancia, comparar casos concretos <a href=\"https:\/\/webhosting.de\/pt\/threading-modelo-de-servidor-orientado-para-eventos-comparacao-de-alojamento-serverperf\/\">Modelos de servidor orientados por eventos<\/a> com conjuntos de threads em testes 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>Compatibilidade: m\u00f3dulos e configura\u00e7\u00f5es t\u00edpicas<\/h2>\n\n<p>Primeiro verifico o <strong>M\u00f3dulos<\/strong>, uma vez que o Worker e o Event exigem seguran\u00e7a de threads. As pilhas cl\u00e1ssicas do mod_php n\u00e3o se adequam, raz\u00e3o pela qual o Prefork continua a fazer sentido neste caso. Por outro lado, se o PHP for executado atrav\u00e9s do PHP-FPM ou do FastCGI, opto claramente pelo Event. O mesmo se aplica a proxies reversos para servidores de aplica\u00e7\u00f5es, microsservi\u00e7os ou back-ends Go\/Node. Nessas configura\u00e7\u00f5es, o \u00abWorker\u00bb e, sobretudo, <strong>Evento<\/strong> a sua resist\u00eancia sem comprometer a compatibilidade.<\/p>\n\n<h2>Configura\u00e7\u00e3o: As diretivas mais importantes<\/h2>\n\n<p>Apresento-te as diretrizes-chave de forma concisa, para que as possas compreender bem e <strong>personalizado<\/strong>. O MaxRequestWorkers limita o n\u00famero de pedidos processados em simult\u00e2neo; no caso do Event, muitas vezes \u00e9 poss\u00edvel aumentar esse valor, uma vez que as liga\u00e7\u00f5es inativas n\u00e3o bloqueiam o sistema. O ThreadsPerChild define o n\u00famero de threads por processo; um valor demasiado baixo reduz o rendimento, enquanto um valor demasiado alto sobrecarrega a CPU. O `ServerLimit` define o limite de processos e, consequentemente, o limite m\u00e1ximo de pedidos paralelos no conjunto. Com o `KeepAliveTimeout`, controla-se durante quanto tempo as liga\u00e7\u00f5es permanecem abertas; quanto maior for o valor, maior ser\u00e1 o benef\u00edcio <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>Compara\u00e7\u00e3o tabular: Worker vs. Event<\/h2>\n\n<p>Vou resumir as caracter\u00edsticas mais importantes numa forma concisa <strong>Tabela<\/strong> juntos, para que possas ver as diferen\u00e7as imediatamente. N\u00e3o substitui um teste de carga, mas ajuda a estruturar a tua vis\u00e3o sobre as caracter\u00edsticas essenciais. L\u00ea os pontos da esquerda para a direita e associa-os ao teu perfil de tr\u00e1fego. Assim, encontrar\u00e1s rapidamente o MPM adequado para a tua arquitetura. O foco est\u00e1 claramente na escalabilidade, nos requisitos de recursos e no comportamento com <strong>Manter em perman\u00eancia<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Crit\u00e9rio<\/th>\n      <th>Worker MPM<\/th>\n      <th>Evento MPM<\/th>\n      <th>efeito<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Gest\u00e3o do Keep-Alive<\/td>\n      <td>O thread permanece associado \u00e0 liga\u00e7\u00e3o<\/td>\n      <td>As liga\u00e7\u00f5es inativas s\u00e3o colocadas em espera pelo ciclo de eventos<\/td>\n      <td>O evento mant\u00e9m as threads de pedidos livres<\/td>\n    <\/tr>\n    <tr>\n      <td>Utiliza\u00e7\u00e3o de recursos<\/td>\n      <td>Mais threads ocupados em modo inativo<\/td>\n      <td>Menos threads ocupados em estado de inatividade<\/td>\n      <td>Menor consumo de RAM\/CPU por pedido ativo<\/td>\n    <\/tr>\n    <tr>\n      <td>Lat\u00eancia sob carga<\/td>\n      <td>Sai mais cedo<\/td>\n      <td>Mant\u00e9m-se est\u00e1vel durante mais tempo<\/td>\n      <td>Melhor resposta<\/td>\n    <\/tr>\n    <tr>\n      <td>Compatibilidade com HTTP\/2<\/td>\n      <td>Organizado<\/td>\n      <td>Muito eficiente<\/td>\n      <td>Vantagens da multiplexa\u00e7\u00e3o<\/td>\n    <\/tr>\n    <tr>\n      <td>Configura\u00e7\u00e3o<\/td>\n      <td>MaxRequestWorkers, ThreadsPerChild, ServerLimit<\/td>\n      <td>Iguais, mais otimiza\u00e7\u00e3o do ciclo de eventos<\/td>\n      <td>O evento permite uma maior utiliza\u00e7\u00e3o da capacidade<\/td>\n    <\/tr>\n    <tr>\n      <td>Compatibilidade<\/td>\n      <td>S\u00e3o necess\u00e1rios m\u00f3dulos \u00e0 prova de threads<\/td>\n      <td>Da mesma forma, de prefer\u00eancia com o PHP-FPM<\/td>\n      <td>O Prefork continua a ser uma op\u00e7\u00e3o do mod_php<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Na pr\u00e1tica: fluxo de trabalho de afina\u00e7\u00e3o e medi\u00e7\u00e3o<\/h2>\n\n<p>Come\u00e7o sempre com uma linha de base limpa <strong>Monitoriza\u00e7\u00e3o<\/strong> e dados de registo. Em seguida, vou variando gradualmente os par\u00e2metros `MaxRequestWorkers` e `ThreadsPerChild` e medo a lat\u00eancia, a taxa de erros e a carga da CPU. Testo o `KeepAliveTimeout` em etapas, porque o tempo ideal depende muito do comportamento do cliente. A partir daqui, vale a pena comparar Event vs. Worker com ferramentas como ab, wrk ou JMeter. S\u00f3 quando as m\u00e9tricas parecerem corretas \u00e9 que fixo o <strong>Perfis<\/strong> e registo os indicadores.<\/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>Quando \u00e9 que o Prefork continua a fazer sentido<\/h2>\n\n<p>Recorro ao Prefork quando n\u00e3o \u00e9 absolutamente necess\u00e1rio utilizar c\u00f3digo seguro para threads <strong>M\u00f3dulos<\/strong> t\u00eam de ser executados. Nesse caso, o isolamento por processo \u00e9 mais importante do que a escalabilidade. Em contrapartida, aceito um consumo de RAM significativamente mais elevado por liga\u00e7\u00e3o. Para aplica\u00e7\u00f5es legadas sem possibilidade de adapta\u00e7\u00e3o, esta continua a ser, muitas vezes, a op\u00e7\u00e3o mais realista. No entanto, assim que utilizo o PHP-FPM ou outros servidores de aplica\u00e7\u00f5es externos, opto por <strong>Evento<\/strong> de forma clara.<\/p>\n\n<h2>Contexto da hospedagem web e escolha do fornecedor<\/h2>\n\n<p>No contexto da hospedagem, presto aten\u00e7\u00e3o aos perfis MPM, porque, muitas vezes, existe um grande n\u00famero de hosts virtuais numa mesma m\u00e1quina <strong>correr<\/strong>. O Event permite aqui a utiliza\u00e7\u00e3o mais eficiente dos recursos, especialmente com HTTP\/2 e TLS. Se a minha pilha de tecnologias exigir o PHP-FPM, defino o Event como padr\u00e3o. Para contextualiza\u00e7\u00e3o e verifica\u00e7\u00e3o t\u00e9cnica, \u00e9 \u00fatil um breve <a href=\"https:\/\/webhosting.de\/pt\/webserver-worker-models-prefork-worker-event-mpm-serverperf\/\">Compara\u00e7\u00e3o entre Prefork, Worker e Event<\/a> antes da escolha final. Quem fizer estes trabalhos de casa obt\u00e9m resultados visivelmente melhores <strong>Tempos de resposta<\/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>Compacto de boas pr\u00e1ticas<\/h2>\n\n<p>Utilizo sempre <strong>PHP-FPM<\/strong> ou outros servidores de aplica\u00e7\u00f5es externos, para que o Event possa atingir o seu pleno potencial. Em seguida, ajusto os par\u00e2metros MaxRequestWorkers e ThreadsPerChild de acordo com os n\u00facleos da CPU e a RAM, e verifico os limites m\u00e1ximos do sistema. No caso de muitos clientes inativos, opto pelo Event, defino deliberadamente o KeepAliveTimeout para um valor mais elevado e monitorizo as lat\u00eancias. Para cargas de trabalho com pedidos muito curtos e um Keep-Alive moderado, o Worker \u00e9 suficiente, desde que os m\u00f3dulos continuem a ser seguros em termos de threads. Sem uma monitoriza\u00e7\u00e3o cont\u00ednua da utiliza\u00e7\u00e3o dos threads, dos erros e <strong>Lat\u00eancias<\/strong> n\u00e3o tomo decis\u00f5es definitivas.<\/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>Exemplos concretos de configura\u00e7\u00e3o para o Event e o Worker<\/h2>\n<p>Apresento dois perfis minimalistas que utilizo como ponto de partida e que, posteriormente, aperfei\u00e7oo com base nos valores medidos. \u00c9 fundamental: <strong>MaxRequestWorkers = ServerLimit \u00d7 ThreadsPerChild<\/strong>. Fa\u00e7o o c\u00e1lculo a partir do or\u00e7amento de RAM e das necessidades por thread (incluindo m\u00f3dulos, TLS e buffers) e vou aumentando gradualmente.<\/p>\n<pre><code>Exemplo #: 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 e ajustar apenas ap\u00f3s medi\u00e7\u00e3o:\n# ListenBacklog 1024\n# ThreadStackSize     1048576   # 1 MB, apenas se os m\u00f3dulos o permitirem\n# AsyncRequestWorkerFactor 2    # Ajuste fino do ciclo de eventos, na maioria das vezes mant\u00e9m-se o valor por predefini\u00e7\u00e3o\n\n# HTTP\/2\nProtocolos h2 http\/1.1\n# H2MaxSessionStreams  100-200  # ajustar com precis\u00e3o consoante a capacidade do backend\n<\/code><\/pre>\n<pre><code>Exemplo #: Worker MPM (pedidos curtos, 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>Eu seguro <strong>MaxConnectionsPerChild<\/strong> (Alias: MaxRequestsPerChild) diferente de 0, para detetar fugas de mem\u00f3ria graduais. <strong>Tempo de espera de manuten\u00e7\u00e3o de conex\u00e3o<\/strong> Defino-o deliberadamente mais alto no \u00abEvent\u00bb, porque as liga\u00e7\u00f5es inativas s\u00e3o econ\u00f3micas; no \u00abWorker\u00bb, mantenho-o baixo para n\u00e3o bloquear os threads.<\/p>\n\n<h2>Ajuste fino do HTTP\/2 com o Event<\/h2>\n<p>Tenho em conta ao <strong>HTTP\/2<\/strong>, que os navegadores abrem poucas liga\u00e7\u00f5es e muitas <strong>Streams<\/strong> multiplexar. Desta forma, o gargalo passa do n\u00famero de liga\u00e7\u00f5es para uma distribui\u00e7\u00e3o justa de threads e para a capacidade do backend. Com o Event, os threads permanecem livres enquanto um stream estiver em espera; isto atenua os picos de lat\u00eancia. Ferramentas pr\u00e1ticas:<\/p>\n<ul>\n  <li><strong>H2MaxSessionStreams<\/strong>: Normalmente, movo-me na faixa dos 50\u2013200. Um valor demasiado elevado gera efeitos \u00abhead-of-line\u00bb no backend; um valor demasiado baixo desperdi\u00e7a o paralelismo.<\/li>\n  <li><strong>MaxRequestWorkers<\/strong>: Com o Event, posso aumentar a carga, desde que a RAM e a CPU o permitam. Estou a monitorizar os percentis 95 e 99 da lat\u00eancia \u00e0 medida que o paralelismo aumenta.<\/li>\n  <li><strong>TLS<\/strong>: Com o ALPN e conjuntos de encripta\u00e7\u00e3o modernos, reduzo os custos do handshake; o evento beneficia ainda mais, uma vez que as fases de inatividade entre os picos de transmiss\u00e3o s\u00e3o geridas de forma eficiente.<\/li>\n<\/ul>\n\n<h2>Limites do sistema operativo e backlogs de sockets<\/h2>\n<p>Antes de cada teste de carga, verifico os limites do sistema; caso contr\u00e1rio, n\u00e3o \u00e9 o MPM que imp\u00f5e restri\u00e7\u00f5es, mas sim o kernel. Para um n\u00famero elevado de liga\u00e7\u00f5es, procuro, em particular, escalar:<\/p>\n<ul>\n  <li><strong>Descritores de ficheiros<\/strong>: ulimit -n e systemd <code>LimiteNOFILE<\/code> Aumento, por exemplo, para 65536 ou mais; o Apache precisa de FD por socket, log e pipe.<\/li>\n  <li><strong>Atraso<\/strong>: <code>net.core.somaxconn<\/code> e <code>tcp_max_syn_backlog<\/code> Defino um valor adequado (por exemplo, 1024\u20134096), para que a fila de aceita\u00e7\u00e3o n\u00e3o fique sobrecarregada.<\/li>\n  <li><strong>\u00c1rea de portos<\/strong> (no caso de um proxy reverso): <code>ip_local_port_range<\/code> aumentaria (por exemplo, 10 000\u201365 000) se houvesse muitas liga\u00e7\u00f5es de sa\u00edda simult\u00e2neas para os back-ends.<\/li>\n  <li><strong>FIN\/Intervalos<\/strong>: Cuidado com <code>tcp_fin_timeout<\/code>: se for demasiado agressivo, pode causar interrup\u00e7\u00f5es na liga\u00e7\u00e3o; s\u00f3 fa\u00e7o altera\u00e7\u00f5es com base nas medi\u00e7\u00f5es.<\/li>\n<\/ul>\n<p>Registo cada ajuste no kernel, juntamente com a justifica\u00e7\u00e3o, e verifico-o atrav\u00e9s de uma nova medi\u00e7\u00e3o da carga. Sem comprova\u00e7\u00e3o, a configura\u00e7\u00e3o predefinida \u00e9, na maioria das vezes, a correta.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o e resolu\u00e7\u00e3o de problemas no dia-a-dia<\/h2>\n<p>Eu ativo <strong>ExtendedStatus<\/strong> e utilizo o \u00abserver-status\u00bb para verificar o <strong>Placar<\/strong>-ler os estados. Na sec\u00e7\u00e3o \u201eEvent\u00bb, vejo muitos sockets inativos\/keep-alive, sem que os threads de trabalho estejam a ser utilizados na totalidade. No registo de erros, aparece \u00abserver reached <strong>MaxRequestWorkers<\/strong> Quando aparece a mensagem \u201csetting, consider raising the MaxRequestWorkers setting\u00bb, o servidor j\u00e1 est\u00e1 a funcionar no limite; aumentei o valor com cautela e observei a utiliza\u00e7\u00e3o da RAM e da CPU, bem como a taxa de erros.<\/p>\n<ul>\n  <li><strong>Campos de medi\u00e7\u00e3o<\/strong>: Nos registos de acesso, registo os tempos de resposta (por exemplo, %D\/%T), os c\u00f3digos de estado e os bytes; estabele\u00e7o uma correla\u00e7\u00e3o entre os picos e a CPU\/IO.<\/li>\n  <li><strong>Sintomas no Worker<\/strong>: Muitas liga\u00e7\u00f5es Keep-Alive inativas, threads ocupados no 100 %, lat\u00eancia crescente, 503\/504 \u2013 ind\u00edcio de threads bloqueados.<\/li>\n  <li><strong>Sintomas durante o evento<\/strong>: Os threads de escuta est\u00e3o sobrecarregados, mas os threads de trabalho est\u00e3o livres \u2013 na maioria das vezes, trata-se de um limite da rede ou do backend, e n\u00e3o do MPM.<\/li>\n  <li><strong>Graceful-Reload<\/strong>: Estou a implementar as altera\u00e7\u00f5es <code>apachectl -k graceful<\/code> para que as liga\u00e7\u00f5es existentes possam escoar corretamente.<\/li>\n<\/ul>\n\n<h2>Planeamento de capacidade: dos n\u00facleos e da RAM ao MaxRequestWorkers<\/h2>\n<p>Fa\u00e7o as contas de forma pragm\u00e1tica: quanta RAM por thread, mais o buffer, pretendo atribuir? No caso do TLS, dos filtros e dos m\u00f3dulos mais comuns, fa\u00e7o um c\u00e1lculo conservador de alguns MB por thread. Depois, defino <strong>MaxRequestWorkers<\/strong> de forma a que os picos de carga nos percentis 95 e 99 sejam geridos sem swap. Ao n\u00edvel da CPU, aplica-se o seguinte: os threads que excedem o n\u00famero de n\u00facleos s\u00f3 ajudam desde que n\u00e3o sejam constantemente exigentes em termos de tempo de execu\u00e7\u00e3o. No caso do Event, atrevo-me a utilizar valores mais elevados, porque as fases de inatividade quase n\u00e3o t\u00eam custo.<\/p>\n<ul>\n  <li><strong>Regras gerais<\/strong>: Iniciar com 32\u201364 threads por processo, 4\u201316 processos; em seguida, proceder \u00e0 medi\u00e7\u00e3o e ao ajuste.<\/li>\n  <li><strong>ThreadStackSize<\/strong>: Se a RAM estiver escassa e os m\u00f3dulos o permitirem, reduzo o tamanho da pilha (com cuidado, realizando um teste de carga).<\/li>\n  <li><strong>M\u00e1ximo de pedidos mantidos ativos<\/strong>: Normalmente mantenho a configura\u00e7\u00e3o predefinida; no caso de clientes \u00abchatty\u00bb, um valor mais elevado pode reduzir a sobrecarga.<\/li>\n<\/ul>\n\n<h2>Cen\u00e1rios de proxy inverso e liga\u00e7\u00f5es ao backend<\/h2>\n<p>Gosto particularmente de utilizar o Event em back-ends de aplica\u00e7\u00f5es, porque <strong>Tomadas frontais<\/strong> estaciona de forma eficiente, enquanto o trabalho propriamente dito decorre no backend. O que \u00e9 decisivo, ent\u00e3o, \u00e9 a agrega\u00e7\u00e3o dos <strong>Liga\u00e7\u00f5es ao backend<\/strong> (mod_proxy):<\/p>\n<ul>\n  <li><strong>Keep-Alive para o backend<\/strong>: Manter ativo para poupar handshakes; tamanho dos pools (<em>max<\/em> (por destino), de acordo com a capacidade do backend.<\/li>\n  <li><strong>Tempos de espera do proxy<\/strong>: Definir claramente os tempos de espera, para que os backends bloqueados n\u00e3o ocupem threads do frontend.<\/li>\n  <li><strong>HTTP\/2 para o backend<\/strong>: Sempre que poss\u00edvel, utilizo o H2 (por exemplo, o h2c interno) para reduzir o n\u00famero de liga\u00e7\u00f5es e aumentar o n\u00famero de fluxos \u2013 o Event funciona bem com isso.<\/li>\n<\/ul>\n<p>Analiso especificamente as percentagens de lat\u00eancia entre o front-end e o back-end; se apenas o tempo do back-end aumentar, o ajuste do MPM por si s\u00f3 n\u00e3o \u00e9 suficiente \u2013 nesse caso, tenho de ajustar os tamanhos dos pools, os tempos de espera ou os recursos do back-end.<\/p>\n\n<h2>Estrat\u00e9gia de implementa\u00e7\u00e3o e migra\u00e7\u00e3o do \u00abWorker\u00bb para o \u00abEvent\u00bb<\/h2>\n<p>Estou a fazer a migra\u00e7\u00e3o em etapas claras: primeiro, verifico o <strong>Lista de m\u00f3dulos<\/strong> (apachectl -M) para verificar a seguran\u00e7a de threads. Tudo o que n\u00e3o for seguro para threads (como o mod_php cl\u00e1ssico) tem de ser removido ou isolado. Depois, ativo o Event, defino valores iniciais conservadores e realizo testes de carga no ambiente de staging. Na implementa\u00e7\u00e3o, come\u00e7o com uma parte do tr\u00e1fego (Canary), comparo as m\u00e9tricas e s\u00f3 depois procedo \u00e0 implementa\u00e7\u00e3o em grande escala.<\/p>\n<ul>\n  <li><strong>comandos<\/strong>: Conforme \u00e9 habitual nesta distribui\u00e7\u00e3o, alternar entre os m\u00f3dulos MPM (por exemplo, a2dismod\/a2enmod) e reiniciar corretamente.<\/li>\n  <li><strong>Plano de conting\u00eancia<\/strong>: Tenho um perfil de worker preparado, para o caso de algum m\u00f3dulo apresentar um comportamento an\u00f3malo na sec\u00e7\u00e3o \u00abEvent\u00bb.<\/li>\n  <li><strong>Documenta\u00e7\u00e3o<\/strong>: Documento todas as altera\u00e7\u00f5es aos limites, aos par\u00e2metros HTTP\/2 e aos valores do kernel com medi\u00e7\u00f5es \u00abantes\u00bb e \u00abdepois\u00bb.<\/li>\n<\/ul>\n\n<h2>Seguran\u00e7a e desempenho do TLS em destaque<\/h2>\n<p>No que diz respeito ao TLS, tenho em conta que os handshakes consomem muitos recursos da CPU e podem aumentar a lat\u00eancia em condi\u00e7\u00f5es de carga elevada. Com <strong>Rein\u00edcio da sess\u00e3o<\/strong> e, atrav\u00e9s da sele\u00e7\u00e3o de algoritmos de encripta\u00e7\u00e3o modernos, reduzo os custos, ao mesmo tempo que otimizo de forma eficiente os per\u00edodos de inatividade. Em combina\u00e7\u00e3o com o HTTP\/2 e o ALPN, evito viagens de ida e volta adicionais. Importante: os buffers TLS e os par\u00e2metros do OpenSSL fazem parte da pegada de RAM por thread \u2013 tenho-os em conta no planeamento da capacidade.<\/p>\n\n<h2>Toler\u00e2ncia a falhas e degrada\u00e7\u00e3o gradual<\/h2>\n<p>Estou a planear para situa\u00e7\u00f5es de sobrecarga: se a CPU estiver saturada ou se o Apache atingir <strong>MaxRequestWorkers<\/strong>, n\u00e3o quero uma avalanche de tentativas de repeti\u00e7\u00e3o. Defino tempos de espera claros, p\u00e1ginas de erro informativas e limites de taxa nos proxies a montante. Com o Event, mant\u00eam-se mais sob press\u00e3o <strong>T\u00f3picos<\/strong> dispon\u00edveis para trabalho efetivo, enquanto as liga\u00e7\u00f5es inativas ficam em espera \u2013 \u00e9 precisamente esta reserva que mant\u00e9m o sistema operacional por mais tempo, at\u00e9 que a carga volte a diminuir ou o dimensionamento autom\u00e1tico entre em a\u00e7\u00e3o.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Na minha atividade atual, aposto em <strong>Evento<\/strong>, assim que a minha pilha utilizar m\u00f3dulos seguros para threads e o PHP-FPM. Esta abordagem reduz o n\u00famero de threads ocupadas em liga\u00e7\u00f5es inativas, mant\u00e9m o tempo de resposta est\u00e1vel e aumenta o n\u00famero de utilizadores atendidos em paralelo. O \u00abWorker\u00bb continua a ser uma op\u00e7\u00e3o s\u00f3lida para pedidos curtos com \u00abKeep-Alive\u00bb moderado, quando o \u00abEvent\u00bb n\u00e3o \u00e9 adequado por motivos organizacionais. Reservo o \u00abPrefork\u00bb para configura\u00e7\u00f5es com m\u00f3dulos n\u00e3o seguros para threads ou c\u00f3digo antigo. Com testes de carga claros, um ajuste preciso das diretivas e um <strong>Monitoriza\u00e7\u00e3o<\/strong> Consegui fazer com que o Apache atingisse a velocidade m\u00e1xima de forma reproduz\u00edvel.<\/p>","protected":false},"excerpt":{"rendered":"<p>MPM Event do Apache vs MPM Worker: Descobre qual o MPM que oferece o melhor desempenho para o otimiza\u00e7\u00e3o moderna de servidores web e quando deves optar pelo 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":"126","_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\/pt\/wp-json\/wp\/v2\/posts\/20730","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=20730"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20730\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20723"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20730"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20730"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20730"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}