{"id":18921,"date":"2026-04-11T08:37:18","date_gmt":"2026-04-11T06:37:18","guid":{"rendered":"https:\/\/webhosting.de\/php-request-queueing-max-children-verarbeitungslimits-performance\/"},"modified":"2026-04-11T08:37:18","modified_gmt":"2026-04-11T06:37:18","slug":"php-enfileiramento-de-pedidos-criancas-maximas-processamento-limites-desempenho","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/php-request-queueing-max-children-verarbeitungslimits-performance\/","title":{"rendered":"Enfileiramento de pedidos PHP e limites de processamento: configura\u00e7\u00e3o \u00f3ptima para servidores est\u00e1veis"},"content":{"rendered":"<p>O enfileiramento de pedidos em PHP limita o n\u00famero de pedidos que o seu servidor processa ao mesmo tempo e, por conseguinte, determina o tempo de resposta, as taxas de erro e a experi\u00eancia do utilizador. Vou mostrar-lhe como <strong>Limites de processamento<\/strong> e eliminar os estrangulamentos e conseguir uma entrega consistente atrav\u00e9s de par\u00e2metros harmonizados.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<p>Para que possa come\u00e7ar de imediato, vou resumir os parafusos de regula\u00e7\u00e3o mais importantes para <strong>PHP-FPM<\/strong> juntos.<\/p>\n<ul>\n  <li><strong>pm.max_children<\/strong>C\u00e1lculo do limite m\u00e1ximo de processos PHP simult\u00e2neos para corresponder \u00e0 RAM.<\/li>\n  <li><strong>lista.backlog<\/strong>Maximizar a prote\u00e7\u00e3o a curto prazo das tentativas de liga\u00e7\u00e3o durante os picos de carga.<\/li>\n  <li><strong>pm.max_requests<\/strong>Recicle processos regularmente para evitar fugas de mem\u00f3ria e incha\u00e7o.<\/li>\n  <li><strong>Intervalos<\/strong>: definir o request_terminate_timeout, o max_execution_time e os tempos limite do servidor Web de forma consistente.<\/li>\n  <li><strong>M\u00e9tricas<\/strong>se o n\u00famero m\u00e1ximo de crian\u00e7as for atingido, verificar continuamente a fila de escuta e os registos lentos.<\/li>\n<\/ul>\n<p>Concentro-me em n\u00fameros-chave claros e efeitos mensur\u00e1veis, para que todos os ajustamentos ao <strong>Limites<\/strong> permanece rastre\u00e1vel. Para cada altera\u00e7\u00e3o, monitorizo os registos e os tempos de resposta antes de planear o passo seguinte e aumentar ou diminuir gradualmente os valores. Desta forma, evito efeitos secund\u00e1rios como a troca de mem\u00f3ria, que pode <strong>Fila de espera<\/strong> dramaticamente mais longos. Com esta abordagem, controlo os picos de carga e mantenho os tempos de resposta est\u00e1veis. O objetivo \u00e9 conseguir uma utiliza\u00e7\u00e3o equilibrada da capacidade que <strong>Recursos<\/strong> de forma eficiente sem sobrecarregar o anfitri\u00e3o.<\/p>\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\/04\/serveroptimierung-php-req-queue-8453.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Como funciona o enfileiramento de pedidos PHP no PHP-FPM<\/h2>\n<p>Cada pedido HTTP de entrada requer o seu pr\u00f3prio <strong>Trabalhador<\/strong>, e um trabalhador apenas serve um pedido de cada vez. Se todos os processos estiverem ocupados, outras chamadas acabam no <strong>Fila de espera<\/strong> e esperar at\u00e9 que um processo fique livre. Se essa fila crescer, os tempos de resposta aumentam e erros como 502\/504 ocorrem com mais frequ\u00eancia. Por isso, presto aten\u00e7\u00e3o a um r\u00e1cio sensato entre o n\u00famero de processos e a mem\u00f3ria dispon\u00edvel, em vez de me concentrar cegamente no paralelismo m\u00e1ximo. Desta forma, obtenho uma taxa de transfer\u00eancia constante sem <strong>RAM<\/strong> ou a CPU separa-se.<\/p>\n\n<h2>Selecionar modos de gest\u00e3o de processos de forma limpa<\/h2>\n<p>Para al\u00e9m dos valores-limite, o <strong>modo pm<\/strong> capacidade de resposta e consumo de recursos:<\/p>\n<ul>\n  <li><strong>pm = din\u00e2mico<\/strong>Eu defino start_servers, min_spare_servers e max_spare_servers. Este modo \u00e9 o meu padr\u00e3o para cargas vari\u00e1veis porque reage rapidamente a aumentos e mant\u00e9m os processos quentes prontos.<\/li>\n  <li><strong>pm = a pedido<\/strong>Os processos s\u00e3o criados apenas quando necess\u00e1rio e s\u00e3o terminados ap\u00f3s process_idle_timeout. Isto poupa RAM para acessos pouco frequentes (admin, staging, cron endpoints), mas pode levar a uma perda de RAM no caso de picos repentinos. <strong>Arranques a frio<\/strong> e maior lat\u00eancia. Por isso, utilizo-o de forma selectiva e com uma lista de pend\u00eancias generosa.<\/li>\n  <li><strong>pm = est\u00e1tico<\/strong>Um n\u00famero fixo de processos. Ideal se eu tiver um <strong>limite superior r\u00edgido<\/strong> e lat\u00eancias particularmente previs\u00edveis (por exemplo, proxy L7 em frente de alguns pontos finais cr\u00edticos). O requisito de RAM \u00e9 claramente calcul\u00e1vel, mas os processos n\u00e3o utilizados ocupam mem\u00f3ria.<\/li>\n<\/ul>\n<p>Eu decido qual o modo mais adequado ao perfil de cada pool. Normalmente, utilizo o din\u00e2mico para frontends com cargas vari\u00e1veis, o ondemand para pools de utilit\u00e1rios e o est\u00e1tico para servi\u00e7os dedicados e cr\u00edticos em termos de lat\u00eancia.<\/p>\n\n<h2>Determinar pm.max_children corretamente<\/h2>\n<p>A alavanca mais importante \u00e9 <strong>pm.max_children<\/strong>, porque este valor define o n\u00famero de pedidos que podem ser executados em simult\u00e2neo. Calculo o tamanho inicial usando a regra geral: (RAM livremente dispon\u00edvel - reserva de 2 GB) dividido pela mem\u00f3ria m\u00e9dia por processo PHP. Como uma suposi\u00e7\u00e3o aproximada, uso 40-80 MB por processo e inicialmente come\u00e7o com 200-300 processos em um host de 32 GB. Sob carga real, aumento ou diminuo gradualmente e verifico se o tempo de espera do processo <strong>Fila de espera<\/strong> diminui e a taxa de erro diminui. Se quiser aprofundar o assunto, pode encontrar informa\u00e7\u00f5es de base sobre os valores de in\u00edcio e limite em <a href=\"https:\/\/webhosting.de\/pt\/php-fpm-gestao-de-processos-pm-max-children-otimizar-nucleo\/\">Otimizar pm.max_children<\/a>.<\/p>\n\n<h2>Coordenar valores iniciais, sobressalentes e em atraso<\/h2>\n<p>Eu fixo <strong>pm.iniciar_servidores<\/strong> para cerca de 15-30 por cento de pm.max_children, de modo a que estejam dispon\u00edveis processos suficientes no in\u00edcio e n\u00e3o haja arranques a frio. Com pm.min_spare_servers e pm.max_spare_servers, defino uma janela razo\u00e1vel para os processos livres, de modo a que os novos pedidos n\u00e3o fiquem \u00e0 espera e, ao mesmo tempo, nenhum tempo ocioso desnecess\u00e1rio ocupe a mem\u00f3ria. Listen.backlog \u00e9 particularmente importante: Este buffer do kernel guarda brevemente tentativas de conex\u00e3o adicionais quando todos os workers est\u00e3o ocupados. Para picos de carga, eu defino valores altos (por exemplo, 65535) para que o <strong>fila de espera<\/strong> n\u00e3o p\u00e1ra antes do pool FPM. Informa\u00e7\u00f5es mais aprofundadas sobre a intera\u00e7\u00e3o entre o servidor Web, o upstream e os buffers podem ser encontradas na s\u00edntese de <a href=\"https:\/\/webhosting.de\/pt\/servidor-web-fila-latencia-tratamento-de-pedidos-fila-do-servidor\/\">Enfileiramento de servidores Web<\/a>.<\/p>\n\n<h2>Limitar os tempos de execu\u00e7\u00e3o dos pedidos e reciclar os processos<\/h2>\n<p>Evito os surtos de mem\u00f3ria com <strong>pm.max_requests<\/strong>, que reinicia todos os processos ap\u00f3s X pedidos. Aplica\u00e7\u00f5es discretas geralmente funcionam bem com 500-800, se houver suspeita de vazamento de mem\u00f3ria eu reduzo para 100-200 e observo o efeito. Al\u00e9m disso, request_terminate_timeout encapsula os outliers, terminando pedidos extremamente longos ap\u00f3s um tempo fixo. A consist\u00eancia \u00e9 importante: eu mantenho o max_execution_time do PHP e os timeouts do servidor web no mesmo corredor para que uma camada n\u00e3o termine antes da outra. Esta intera\u00e7\u00e3o mant\u00e9m o <strong>Trabalhador<\/strong> livre e protege a piscina do congestionamento.<\/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\/04\/PHP_Server_Limits_Besprechung_4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Tornar as filas vis\u00edveis: Registos e m\u00e9tricas<\/h2>\n<p>Leio regularmente os registos do FPM e presto aten\u00e7\u00e3o a <strong>m\u00e1ximo de crian\u00e7as alcan\u00e7adas<\/strong>, porque esta entrada indica que o limite superior dos processos foi atingido. Ao mesmo tempo, monitorizo a fila de escuta, que revela um atraso crescente no buffer de entrada. Em combina\u00e7\u00e3o com request_slowlog_timeout, obtenho tra\u00e7os de pilha para pontos lentos no c\u00f3digo e isolo os trav\u00f5es da base de dados ou da API. Correlaciono o upstream_response_time dos registos do servidor Web com o request_time e os c\u00f3digos de estado para identificar a origem dos longos tempos de resposta. Isto permite-me reconhecer se o estrangulamento no PHP-FPM, o <strong>Base de dados<\/strong> ou a rede a montante.<\/p>\n\n<h2>Perfis de carga de trabalho: Limitado \u00e0 CPU vs. Limitado \u00e0 IO<\/h2>\n<p>Para processos com muita CPU, eu dimensiono o <strong>Paralelismo<\/strong> Eu sou cauteloso e oriento-me de perto para o n\u00famero de vCPU, porque os processos adicionais dificilmente trazem qualquer rendimento. Se se tratar principalmente de uma carga de IO com acessos a bases de dados ou APIs externas, posso permitir mais processos, desde que o or\u00e7amento de RAM seja suficiente. Os checkouts de com\u00e9rcio eletr\u00f3nico beneficiam de timeouts mais longos (por exemplo, 300 s) para completar os m\u00e9todos de pagamento sem cancelamentos. Intercepto as vendas r\u00e1pidas definindo o listen.backlog como elevado e aumentando a janela de reserva. As informa\u00e7\u00f5es sobre o equil\u00edbrio entre o n\u00famero de processos e o desempenho do anfitri\u00e3o est\u00e3o inclu\u00eddas no guia para <a href=\"https:\/\/webhosting.de\/pt\/php-workers-hosting-bottleneck-guide-balance\/\">PHP-Workers como um estrangulamento<\/a>.<\/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\/04\/php-request-queue-servers-6591.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>C\u00e1lculos e dimensionamento de amostras<\/h2>\n<p>Come\u00e7o por calcular a mem\u00f3ria por processo e depois obtenho uma <strong>Limite superior<\/strong> off. Em seguida, testo sob carga real e observo se a fila diminui e a taxa de transfer\u00eancia aumenta. Valores iniciais conservadores reduzem o risco de troca e mant\u00eam o tempo de resposta uniforme. De seguida, refino em pequenos passos para ter a certeza de que n\u00e3o se notam quaisquer efeitos secund\u00e1rios. A tabela a seguir fornece orienta\u00e7\u00f5es sobre os valores iniciais e os efeitos sobre o <strong>Fila de espera<\/strong>.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Par\u00e2metros<\/th>\n      <th>Efeito<\/th>\n      <th>Valor inicial (exemplo)<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>pm.max_children<\/td>\n      <td>M\u00e1x. simult\u00e2neo <strong>Processos<\/strong><\/td>\n      <td>200-300 (com 32 GB)<\/td>\n      <td>Comparar com o or\u00e7amento de RAM e o tamanho do processo<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.iniciar_servidores<\/td>\n      <td>N\u00famero inicial de trabalhadores<\/td>\n      <td>15-30 % de max_children<\/td>\n      <td>Evitar arranques a frio, mas manter a marcha lenta ao m\u00ednimo<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.min_servidores_sobressalentes<\/td>\n      <td>Gr\u00e1tis <strong>Trabalhador<\/strong> M\u00ednimo<\/td>\n      <td>z. B. 20<\/td>\n      <td>Inclus\u00e3o direta de novos pedidos<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.max_spare_servers<\/td>\n      <td>Trabalhador livre M\u00e1ximo<\/td>\n      <td>z. B. 40<\/td>\n      <td>Limitar o consumo de RAM dos processos inactivos<\/td>\n    <\/tr>\n    <tr>\n      <td>lista.backlog<\/td>\n      <td>Mem\u00f3ria interm\u00e9dia do kernel para tentativas de liga\u00e7\u00e3o<\/td>\n      <td>65535<\/td>\n      <td>Amortecer os picos de carga e reduzir as interrup\u00e7\u00f5es de liga\u00e7\u00e3o<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.max_requests<\/td>\n      <td>Reciclagem <strong>Intervalo<\/strong><\/td>\n      <td>500-800, com fugas de 100-200<\/td>\n      <td>Minimizar o incha\u00e7o da mem\u00f3ria e as interrup\u00e7\u00f5es<\/td>\n    <\/tr>\n    <tr>\n      <td>request_terminate_timeout<\/td>\n      <td>Limite r\u00edgido de pedidos<\/td>\n      <td>300-600 s<\/td>\n      <td>Consistente com os tempos limite do PHP e do servidor Web<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Modelos pr\u00e1ticos para pools PHP FPM<\/h2>\n<p>Para uma loja com muitos acessos de leitura, defino <strong>N\u00fameros do processo<\/strong> e aumentar a janela de reserva para que as solicita\u00e7\u00f5es n\u00e3o fiquem em fila de espera. Para p\u00e1ginas de conte\u00fado com armazenamento em cache, um n\u00famero significativamente menor de trabalhadores costuma ser suficiente, desde que o NGINX ou o Apache forne\u00e7am conte\u00fado est\u00e1tico com efici\u00eancia. Separo as configura\u00e7\u00f5es de v\u00e1rios pools de acordo com as partes da aplica\u00e7\u00e3o que t\u00eam perfis de mem\u00f3ria diferentes, para que nenhum pool pesado substitua os outros. Defino pools separados com suas pr\u00f3prias regras de tempo limite para cron ou queue workers. \u00c9 assim que mantenho o sistema interativo <strong>Tr\u00e1fego<\/strong> gratuito e n\u00e3o atrasa nenhuma a\u00e7\u00e3o do utilizador.<\/p>\n\n<h2>Tempo limite do servidor Web, upstream e sockets<\/h2>\n<p>Considero os tempos limite do FastCGI e do proxy de <strong>Nginx<\/strong> ou Apache na mesma janela que os timeouts do FPM para que nenhuma camada termine muito cedo. Prefiro sockets Unix a TCP se ambos os servi\u00e7os estiverem a correr na mesma m\u00e1quina, porque a lat\u00eancia permanece m\u00ednima. Para configura\u00e7\u00f5es distribu\u00eddas, eu uso TCP com valores est\u00e1veis de keepalive e um pool de conex\u00f5es suficientemente grande. Para alto paralelismo, o nginx sincroniza worker_connections e os valores de backlog do FPM. Isso garante que os redireccionamentos permane\u00e7am r\u00e1pidos e evito o tempo de inatividade devido a liga\u00e7\u00f5es demasiado apertadas. <strong>A montante<\/strong>-limites.<\/p>\n\n<h2>Caching, OPCache e base de dados como alavancas<\/h2>\n<p>Resolvo muitos problemas dos servidores reduzindo as opera\u00e7\u00f5es dispendiosas e minimizando os custos de <strong>Tempo de resposta<\/strong> inferior. Ativo a OPCache, aumento o limite de mem\u00f3ria da cache de forma sensata e asseguro uma elevada taxa de acerto da cache. Para obter resultados recorrentes, utilizo a cache da aplica\u00e7\u00e3o para que os processos PHP sejam conclu\u00eddos mais rapidamente. Do lado da base de dados, optimizo as consultas lentas e ativo as caches de consulta adequadas ao sistema utilizado. Cada milissegundo poupado reduz a carga sobre o <strong>Fila de espera<\/strong> e aumenta o rendimento por trabalhador.<\/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\/04\/php_server_setup_8943.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Mecanismos de emerg\u00eancia e rein\u00edcios seguros<\/h2>\n<p>Eu ativo <strong>limiar_de_rein\u00edcio_de_emerg\u00eancia<\/strong> e emergency_restart_interval para que o FPM master reinicie se demasiados filhos falharem numa sucess\u00e3o r\u00e1pida. Esse rein\u00edcio controlado evita rea\u00e7\u00f5es em cadeia e mant\u00e9m o servi\u00e7o dispon\u00edvel. Ao mesmo tempo, defino limites claros para a mem\u00f3ria e o n\u00famero de processos para evitar escalonamentos. As verifica\u00e7\u00f5es de integridade no lado upstream removem automaticamente backends defeituosos do pool e reduzem as taxas de erro. Isso mant\u00e9m o <strong>Disponibilidade<\/strong> enquanto eu investigo a causa real.<\/p>\n\n<h2>Ajuste fino dos limites do sistema operativo e do systemd<\/h2>\n<p>Portanto, isso <strong>lista.backlog<\/strong> realmente tem efeito, eu ajusto os limites do kernel. O valor do SO net.core.somaxconn deve ser pelo menos t\u00e3o alto quanto o backlog definido, caso contr\u00e1rio o sistema corta a fila. Tamb\u00e9m verifico o n\u00famero de descritores de ficheiros permitidos: No pool FPM posso definir rlimit_files, ao n\u00edvel do servi\u00e7o asseguro LimitNOFILE (systemd) e ao n\u00edvel do kernel fs.file-max. O servidor web precisa de reservas semelhantes para n\u00e3o atingir os seus limites mais cedo.<\/p>\n<p>Para lat\u00eancias mais est\u00e1veis, reduzo <strong>vm.swappiness<\/strong>, para que o kernel n\u00e3o desloque prematuramente as p\u00e1ginas de mem\u00f3ria ativamente utilizadas. Em configura\u00e7\u00f5es cr\u00edticas de lat\u00eancia, eu desativo o <strong>P\u00e1ginas enormes transparentes<\/strong>, para evitar falhas de p\u00e1gina longas. Se o FPM for executado via TCP, eu tamb\u00e9m sincronizo os par\u00e2metros net.ipv4.tcp_max_syn_backlog e reuse\/keepalive. Esses detalhes do SO parecem impercept\u00edveis, mas eles decidem se as filas <em>suave<\/em> expiram ou se as liga\u00e7\u00f5es j\u00e1 foram rejeitadas antes do FPM.<\/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\/04\/php_request_queue_8432.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Medir a carga de mem\u00f3ria por processo<\/h2>\n<p>Em vez de fazer estimativas generalizadas, me\u00e7o os <strong>Consumo real<\/strong> por trabalhador sob carga real. Utilizo ferramentas como ps, smem ou pmap, filtro os filhos do php-fpm e fa\u00e7o a m\u00e9dia dos valores RSS enquanto os pedidos est\u00e3o a decorrer. \u00c9 importante ter em conta a utiliza\u00e7\u00e3o da OPCache partilhada: a mem\u00f3ria partilhada n\u00e3o \u00e9 contada v\u00e1rias vezes. Derivo o pm.max_children do valor m\u00e9dio e tamb\u00e9m planeio uma reserva para que a m\u00e1quina n\u00e3o se depare com um estrangulamento mesmo durante os picos. <strong>Troca<\/strong> inclina-se.<\/p>\n<p>Repito esta medi\u00e7\u00e3o ap\u00f3s altera\u00e7\u00f5es de fun\u00e7\u00f5es ou de vers\u00f5es. Novas funcionalidades, mais depend\u00eancias ou altera\u00e7\u00f5es nas estruturas podem aumentar significativamente a pegada por processo. Isto mant\u00e9m o n\u00famero de processos realista e a fila de espera curta.<\/p>\n\n<h2>Estado do PHP FPM, ping e m\u00e9tricas em tempo real<\/h2>\n<p>Para uma avalia\u00e7\u00e3o r\u00e1pida da situa\u00e7\u00e3o, ativo <strong>pm.status_path<\/strong> e um <strong>Ponto de extremidade de ping<\/strong> (ping.path\/ping.response). Acima disto, posso ver valores-chave como a liga\u00e7\u00e3o aceite, o comprimento da fila de escuta, os processos inactivos\/ocupados, o n\u00famero m\u00e1ximo de crian\u00e7as atingidas e a sua progress\u00e3o. Leio estes valores periodicamente e defino valores limite: se a fila de escuta aumenta permanentemente, aumento os processos ou elimino a causa dos pedidos lentos. Se o n\u00famero m\u00e1ximo de filhos alcan\u00e7ados aumentar enquanto o tempo ocioso permanecer baixo, o pool \u00e9 muito pequeno ou est\u00e1 bloqueado por <strong>corredores longos<\/strong>.<\/p>\n<p>Tamb\u00e9m separo os pools com perfis diferentes para que os picos numa \u00e1rea (por exemplo, importa\u00e7\u00f5es de API) n\u00e3o fa\u00e7am com que o tr\u00e1fego interativo fique de rastos. Para casos de diagn\u00f3stico, aumento temporariamente o log_level e deixo o slowlog capturar mais amostras, mas depois reduzo-o novamente para manter a carga de E\/S baixa.<\/p>\n\n<h2>Uploads, buffering e corpos de pedidos grandes<\/h2>\n<p>Grandes uploads podem sobrecarregar os trabalhadores desnecessariamente se o PHP tiver que ler o corpo do pedido primeiro. Eu me certifico de que o servidor web <strong>amortecedores<\/strong> (por exemplo, fastcgi_request_buffering para NGINX), para que o FPM s\u00f3 inicie quando o corpo estiver completo. Isso significa que nenhum trabalhador bloqueia durante o upload. Utilizo client_max_body_size, post_max_size e max_input_time para controlar o tamanho e a dura\u00e7\u00e3o dos pedidos sem comprometer os endpoints. Se houver ficheiros pelo meio, atribuo uma mem\u00f3ria tempor\u00e1ria (SSD) suficientemente r\u00e1pida para evitar bloqueios de buffer.<\/p>\n<p>Para pontos de extremidade com corpos muito grandes (por exemplo, exporta\u00e7\u00f5es\/importa\u00e7\u00f5es), defino pools dedicados com seus pr\u00f3prios tempos limite e menos paralelismo. Isto deixa os trabalhadores padr\u00e3o livres e o <strong>Fila de espera<\/strong> das ac\u00e7\u00f5es importantes do utilizador.<\/p>\n\n<h2>Liga\u00e7\u00f5es \u00e0 base de dados e limites do grupo<\/h2>\n<p>Mesmo a melhor defini\u00e7\u00e3o de FPM \u00e9 in\u00fatil se o <strong>Base de dados<\/strong> anteriormente limitado. Alinho o n\u00famero m\u00e1ximo de processos PHP simult\u00e2neos com a capacidade real dispon\u00edvel da BD. Para liga\u00e7\u00f5es persistentes ou pools de liga\u00e7\u00f5es, certifico-me de que a soma de todos os pools \u00e9 <em>em<\/em> max_connections permanece. Se existirem muitas consultas curtas, ajuda limitar moderadamente o paralelismo do PHP para que a base de dados n\u00e3o se desloque entre milhares de sess\u00f5es.<\/p>\n<p>As transac\u00e7\u00f5es lentas provocam rapidamente um atraso na fila de espera do FPM. Por isso, analiso os tempos de espera dos bloqueios, a utiliza\u00e7\u00e3o de \u00edndices e os planos de consulta. Cada redu\u00e7\u00e3o no tempo de execu\u00e7\u00e3o do BD reduz diretamente o PHP<strong>Dura\u00e7\u00e3o do documento<\/strong> e reduz os comprimentos das filas de espera.<\/p>\n\n<h2>Lan\u00e7amentos e implementa\u00e7\u00f5es sem picos<\/h2>\n<p>Ao lan\u00e7ar novas vers\u00f5es, evito caches frias e tempestades de processos. Utilizo <strong>recarregar<\/strong> em vez de reiniciar o sistema, para que os pedidos dos trabalhadores existentes terminem de forma limpa (note process_control_timeout). Eu aque\u00e7o o OPCache em um est\u00e1gio inicial, executando caminhos cr\u00edticos uma vez antes de mudar ou trabalhando com pr\u00e9-carregamento. Isso evita que muitos workers analisem arquivos de classe ao mesmo tempo e o <strong>Tempo de resposta<\/strong> aumenta a passos largos.<\/p>\n<p>Com as estrat\u00e9gias azul\/verde ou can\u00e1rio, aumento gradualmente a carga e monitorizo as p\u00e1ginas de estado. S\u00f3 quando a fila de espera, a taxa de erro e as lat\u00eancias se mant\u00eam est\u00e1veis \u00e9 que aumento a propor\u00e7\u00e3o de tr\u00e1fego. Esta abordagem controlada protege contra picos de carga durante a implementa\u00e7\u00e3o.<\/p>\n\n<h2>Especialidades de contentores e VM<\/h2>\n<p>Nos contentores, a perce\u00e7\u00e3o <strong>Volume total de armazenamento<\/strong> muitas vezes inferior aos relat\u00f3rios do anfitri\u00e3o. Eu alinho o pm.max_children estritamente com o limite do cgroup e planeio uma reserva contra o OOM killer. Os limites de mem\u00f3ria no PHP (memory_limit) e o footprint por processo devem corresponder, caso contr\u00e1rio, um \u00fanico outlier \u00e9 suficiente para encerrar o container.<\/p>\n<p>Se n\u00e3o houver swap no contentor, \u00e9 mais prov\u00e1vel que ocorram cancelamentos for\u00e7ados. \u00c9 por isso que mantenho os processos conservadores, ativo a reciclagem e monitorizo os picos de RSS na carga de produ\u00e7\u00e3o. V\u00e1rios pools enxutos s\u00e3o geralmente mais robustos aqui do que um pool grande e monol\u00edtico.<\/p>\n\n<h2>Degrada\u00e7\u00e3o e contrapress\u00e3o control\u00e1veis<\/h2>\n<p>Se o <strong>Fila de espera<\/strong> Baseio-me numa degrada\u00e7\u00e3o controlada: entrego deliberadamente o 503 com tentativas posteriores para pontos de extremidade n\u00e3o cr\u00edticos em caso de sobrecarga, reduzo as funcionalidades dispendiosas (por exemplo, pesquisas em direto) e limito o acesso paralelo aos pontos de acesso. Desta forma, o sistema mant\u00e9m-se recetivo enquanto eu corrijo a causa, em vez de todos os utilizadores ficarem sem tempo.<\/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\/04\/php-serverraum-1635.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Brevemente resumido<\/h2>\n<p>Eu trago <strong>Enfileiramento de pedidos PHP<\/strong> sob controlo, combinando inteligentemente o n\u00famero de processos simult\u00e2neos com o or\u00e7amento de RAM e o tipo de carga. Os valores elevados de backlog amortecem os picos, os tempos limite a todos os n\u00edveis encaixam-se perfeitamente e a reciclagem elimina os problemas de mem\u00f3ria. Os registos e as m\u00e9tricas mostram-me se a fila est\u00e1 a crescer, onde os pedidos est\u00e3o bloqueados e quando devo apertar o passo. Com ajustes cuidadosos e caching direcionado, reduzo o tempo de processamento por pedido e aumento o rendimento. Desta forma, os servidores fornecem de forma consistente e evitam custos elevados. <strong>Intervalos<\/strong> na vida quotidiana.<\/p>","protected":false},"excerpt":{"rendered":"<p>Dominar o enfileiramento de pedidos em PHP: otimizar o php max children e o tratamento de filas de espera no servidor. Guia com dicas pr\u00e1ticas para um desempenho est\u00e1vel sob carga.<\/p>","protected":false},"author":1,"featured_media":18914,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-18921","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-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":"405","_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":"PHP Request Queueing","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":"18914","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/18921","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=18921"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/18921\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/18914"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=18921"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=18921"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=18921"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}