Saltar para o conteúdo 
Um elevado número de visitantes gera picos de carga em segundos - se o PHP worker, a base de dados e a cache não funcionarem, a chamada à página termina no Tempo limite do WordPress. Vou mostrar-lhe porque é que os pedidos ficam bloqueados, como pode identificar a causa e utilizar definições e actualizações específicas para eliminar os tempos limite sob carga - permanentemente eficaz.
Pontos centrais
- CausasTrabalhadores PHP sobrecarregados, base de dados lenta, falta de cache
- DiagnósticoRegistos do servidor, testes de carga, verificações de plug-ins e análise de consultas
- ImediatamenteAumentar os limites do PHP, alterar o WP-Cron, reparar o .htaccess
- OtimizaçãoArmazenamento em cache, cache de objectos, afinação de imagens e activos, CDN
- EscalonamentoAlojamento mais forte, mais trabalhadores PHP, ajuste dos limites de ligação
Porque é que uma carga elevada provoca timeouts
Um aumento do número de pedidos de informação simultâneos consome primeiro o espaço livre. CPU, então as E/S e os bloqueios da base de dados bloqueiam e os tempos de resposta aumentam. Muitas vezes, vejo os PHP workers a ficarem cheios enquanto os novos pedidos ficam na fila de espera e depois dão origem a um erro 504 ou 502 - um clássico Tempo limite. O alojamento partilhado agrava esta situação, porque partilha recursos com outros projectos e os picos vão-se acumulando. Ainda mais traiçoeiro: consultas de bases de dados não optimizadas em wp_options ou posts com revisões que custam segundos. Combinado com uma cache de página em falta, acaba por não sobrar tempo para o sítio.
502 vs. 504: Interpretar corretamente as imagens de erro
Antes de fotografar, distingo os sintomas: A 502 Gateway inválido indica frequentemente um processo de backend PHP falhado ou inacessível (reinicie o FPM, verifique os limites). A 504 Tempo limite do gateway sinaliza que o upstream (PHP-FPM) está a responder muito lentamente - geralmente o resultado de trabalhadores bloqueados, consultas lentas ou muito apertadas tempo_limite_de_leitura-valores no proxy. Se ambos os erros ocorrerem alternadamente, o foco está nos comprimentos de fila e nos limites de conexão: O proxy ainda pode aceitar novas conexões, mas o FPM não aceita mais trabalhos ou os recusa devido ao excesso de preenchimento.
Encontre a causa: Diagnóstico em minutos
Começo pelos registos de erros e de acesso, porque é aí que reconheço os picos de Pedidos e tempos de execução longos imediatamente. Em seguida, verifico a CPU, a RAM, as E/S e os processos PHP activos - se os trabalhadores estão no seu limite ou se as consultas lentas dominam. Ao nível da aplicação, ligo o registo de depuração para ver acções e ganchos longos e identificar consultas com falhas. Plugins para o isolar. Em seguida, desativo todas as extensões e ativo-as individualmente até que o gatilho seja determinado. Finalmente, simulo o carregamento para ver quando começa a falhar e se a cache e a cache de objectos têm efeito.
Medidas imediatas que têm um efeito percetível
Primeiro, aumento o tempo de execução e a memória para que a execução do Processos não morrem em timeout: em wp-config.php com set_time_limit(300); e por define('WP_MEMORY_LIMIT','512M');. Se for permitido, defino em .htaccess php_value max_execution_time 300 e php_value memory_limit 512M para mais Tampão. Depois desactivei o WP-Cron através de define('DISABLE_WP_CRON', true); e configurei um cron do sistema real para que os pedidos de página não accionem as execuções do cron. Tenho o diálogo de permalink para gerar um novo .htaccess se o ficheiro estiver corrompido. Por fim, esvazio todas as caches e verifico, na janela anónima, se o TTFB cai ou permanece estável.
Configurar especificamente os tempos limite do servidor Web e do proxy
Certifico-me de que a cadeia do servidor Web e do PHP-FPM tem janelas de tempo suficientes, mas não gera quaisquer blocos inactivos. Para o NGINX, ajusto fastcgi_read_timeout, fastcgi_connect_timeout e tempo_limite_de_envio moderadamente ascendente (por exemplo, 60-120 s), enquanto tempo de espera de keepalive permanece bastante curto para não ocupar espaços. Atrás de um proxy reverso (balanceador de carga) estão tempo_limite_de_leitura_proxy e tempo limite de ligação do proxy ambos têm de corresponder ao FPM e ao orçamento da aplicação. No Apache, limito Tempo de espera de manutenção de conexão (2-5 s) e aumentar MaxRequestWorkers apenas se as reservas de RAM forem suficientes para os processos adicionais. A regra é: os tempos limite devem ser suficientemente grandes, mas a duração e o número de ligações devem ser controlados para que não sejam criadas ligações zombie.
Definir corretamente o PHP-FPM, os processos e os limites
Os time-outs ocorrem frequentemente porque estão a ser executados muito poucos PHP workers ou porque estão bloqueados durante demasiado tempo - aqui ajudo a decidir PHP-FPM através de pm=dynamic/ondemand e limites sensatos. Um valor inicial aproximado para pm.max_childrenRAM disponível para o PHP dividida pelo tamanho médio do processo, depois deixe uma reserva de 20-30% para que o servidor possa respirar. pm.max_requests evita fugas de memória, e pm.process_idle_timeout reduz os custos de inatividade se a carga flutuar. Eu ativo estritamente a Opcache para que o intérprete não recompile constantemente e o TTFB diminua significativamente. Se quiser aprofundar o assunto, pode encontrar práticas Definições PHP-FPM, que utilizo como base antes de escalar ou adaptar o tema ao NGINX/Apache.
Apache/NGINX/LiteSpeed: modelos de trabalho e keep-alive
Escolho o modelo de trabalhador para corresponder ao perfil de tráfego: Apache com mpm_event é melhor do que prefork e harmoniza-se com o FPM. O NGINX beneficia de alguns processos_trabalhadores (auto) e alta ligações_trabalhadores, para servir muitos clientes simultâneos. O LiteSpeed/LSAPI vincula o PHP de forma eficiente, mas requer Max-Conns personalizados no lado do PHP. Manter em permanência Mantenho-o ativo, mas curto: tempos de espera curtos e keepalive_requests evitar que clientes ociosos bloqueiem slots. Isto compensa em HTTP/2 e HTTP/3, uma vez que vários activos são executados através de uma ligação e a sobrecarga é reduzida.
Simplifique e acelere a sua base de dados
O travão mais comum está localizado no Base de dadosrevisões inchadas, transientes antigos e uma carga excessiva de autoload em wp_options. Arrumo regularmente, reduzo as revisões, elimino os transientes expirados e mantenho autoload='yes' pequeno em geral, para que o WordPress não carregue centenas de kilobytes no arranque. Optimizo as tabelas utilizando a ferramenta DB e verifico se faltam Índices para condições WHERE frequentes. Para dados multimédia de grande dimensão, confio no descarregamento ou em consultas de metadados eficientes para evitar a explosão de JOINs. Se necessário, eu também levanto max_allowed_packet e utilizar uma cache de objectos (Redis/Memcached), o que reduz visivelmente a carga nos acessos de leitura.
Parâmetros MySQL/InnoDB e análise de consultas lentas
Eu ativo o Registos de consulta lentos temporário (pequeno long_query_time-por exemplo, 0,2-0,5 s) para tornar visíveis os valores anómalos. Para a dimensão InnoDB I innodb_buffer_pool_size (50-70% da DB-RAM) para que os dados quentes sejam armazenados na memória. innodb_log_file_size e innodb_flush_log_at_trx_commit Faço ajustes consoante os requisitos de consistência. Um SSD/NVMetmpdir acelera os grandes tipos, e penso que max_conexões em equilíbrio com o número de PHP workers e pooling de conexão para que o banco de dados não tenha que fazer thrash. Importante: Evite armadilhas de autocommit e transações longas, pois elas prolongam os bloqueios e diminuem a velocidade de cadeias de páginas inteiras.
Caching e CDN: aliviar a carga da aplicação
O caching de páginas fornece HTML sem tocar no PHP ou na base de dados - esta é a maior vantagem durante os picos de tráfego. Alavanca. Defino uma cache de página inteira com um TTL longo, diferencio entre utilizadores com sessão iniciada e convidados e ativo o „stale-while-revalidate“ para que as páginas permaneçam rápidas mesmo durante as reconstruções. Uma cache de objectos acelera a repetição Consultas, enquanto uma CDN fornece activos estáticos perto do utilizador e reduz enormemente a carga da Origem. Converto imagens para WebP, ativo o carregamento lento e combino-o com HTTP/2 ou HTTP/3 para que muitos ficheiros fluam em paralelo. Este guia para Cache de página inteira, a que dou sempre prioridade durante os picos de carga.
Estratégia da cache: Chaves, variantes e proteção contra a debandada
Defino chaves de cache precoces e estáveis: caminho, anfitrião, cookies relevantes (o menor número possível) e tipo de dispositivo. Defino deliberadamente os cookies que personalizam (por exemplo, cesto de compras, moeda) como Variar ou contorno-os com cache fragmentado. Contra Cache-Stampede ajuda a „stale-while-revalidate“, o microcaching (1-10 s) no servidor Web e o pré-aquecimento de rotas críticas antes das campanhas. Eu trato da limpeza InvalidaçãoEliminar especificamente quando o conteúdo é publicado em vez de limpar toda a cache. Isto mantém as taxas de acerto elevadas e os tempos de resposta constantes - mesmo sob carga total.
Comparação de alojamento e actualizações sensatas
A dada altura, chega-se a um ponto em que os limites do pacote entram em vigor - então o sítio precisa de mais Recursos em vez de fazer ajustes finos. Quando as coisas ficam muito ocupadas, deixo os ambientes partilhados e passo para ofertas geridas com CPU/RAM dedicadas ou para um VPS com NGINX/LiteSpeed e armazenamento NVMe. IOPS rápido, PHP workers suficientes e o PHP 8+ mais recente com Cache. Para picos recorrentes, o dimensionamento automático ajuda a dimensionar o trabalhador e a base de dados sem intervenção manual. A visão geral a seguir mostra opções comuns e para que elas são adequadas.
| Local | Fornecedor/Tipo | Espessuras de núcleo | Recomendado para |
|---|---|---|---|
| 1 | webhoster.de (Gerido) | Escalonamento automático, SSD NVMe, CPU/RAM elevada, WP gerido | Tráfego elevado, escalonamento |
| 2 | Alojamento WP gerido | Armazenamento em cache integrado, trabalhadores PHP optimizados | Carga média |
| 3 | VPS com NGINX/LiteSpeed | IOPS elevado, recursos dedicados | Sítios sofisticados |
Escalonamento, limites de conexão e PHP workers
O paralelismo é interrompido se o servidor Web, o PHP-FPM ou a base de dados forem demasiado estreitos. Limites conjunto. Equilíbrio I pm.max_children com o tamanho real do processo, regula os keepalives do servidor Web e verifica os pools de ligações MySQL. A propósito, demasiados trabalhadores podem esgotar a RAM e entupir o I/O - por isso, procedo passo a passo e meço. Se ocorrerem erros 500 ou 504 sob carga, verifico os limites de ligação, os tempos limite e os comprimentos de fila em conjunto. Uma explicação compacta das armadilhas de limite típicas pode ser encontrada neste artigo sobre Limites de ligação, o que muitas vezes me poupa minutos na análise da causa.
Armazenamento em cache eficiente do WooCommerce e das áreas dinâmicas
O comércio eletrónico desafia a estratégia de cache: Coloco totalmente em cache as páginas de categorias, as páginas de produtos e o conteúdo do CMS, enquanto o cesto de compras, o checkout e „A minha conta“ são especificamente excluídos da cache. Fragmentos de carrinho e banners personalizados, recarregando ou fragmentando pequenas partes dinâmicas através de JavaScript. Os cookies como a moeda, o país ou a sessão só acabam no Variar, quando é inevitável; caso contrário, destroem a taxa de acerto. Aqueço as acções planeadas (por exemplo, vendas) para que nenhuma cache fria aqueça no início. Limito os pontos de extremidade Ajax e REST do administrador agrupando consultas, armazenando em cache os resultados e limitando o polling.
Testes de carga, monitorização e alerta
Não me baseio no sentimento, provo os efeitos com Medições. Antes das campanhas, simulo vagas de visitantes, aumento gradualmente a concorrência e verifico em que carga o TTFB e a taxa de erro aumentam. As ferramentas APM mostram-me as transacções, as consultas e as chamadas externas mais lentas - é exatamente aqui que aplico o meu efeito de alavanca. Os alertas sobre a CPU, a RAM, a taxa de 5xx e os tempos de resposta avisam-me atempadamente para que eu possa estar preparado antes do verdadeiro Falha reagir. Em seguida, repito o teste com a cache activada para me certificar de que as optimizações funcionam com carga total.
Proteger serviços externos e pedidos HTTP
Muitos timeouts resultam do bloqueio de chamadas HTTP em temas/plugins. Eu defino janelas de tempo apertadas para wp_remote_get()/wp_remote_post() (tempos limite de ligação/leitura), criar alternativas e mover sincronizações dispendiosas para trabalhos em segundo plano. Verifico a resolução do DNS e o SSL handshake separadamente - resolvedores ou cadeias de certificados defeituosos tornam as coisas visivelmente mais lentas. Faço cache dos resultados recorrentes localmente para que as falhas das APIs externas não afectem o site. Princípio: O E/S externo nunca deve dominar o tempo de execução do pedido.
Segurança, tráfego de bots e regras WAF
Protejo a aplicação contra tráfego inútil: Limites de taxa nos pontos finais de início de sessão, XML-RPC e pesquisa, regras rigorosas contra scrapers e bad bots, bem como um acelerador para crawlers agressivos. 429/503 com Repetir após ajudam a manter a capacidade livre para os utilizadores reais. Um WAF upstream classifica os picos da Camada 7 e bloqueia os vectores de ataque conhecidos antes de terem impacto no PHP/DB. Para os media, ativo uma cache sensata (ETag/Last-Modified) para que as chamadas repetidas quase não gerem custos de servidor.
Limites do sistema e afinação do SO
Se as ligações forem repentinamente rejeitadas sob carga, examino os parâmetros do SO: fs.file-max e descritores abertos para o servidor Web/DB, net.core.somaxconn e net.ipv4.ip_local_port_range para muitas tomadas em simultâneo. Um demasiado pequeno atraso ou agressivo tcp_fin_timeout cria estrangulamentos. Desloco os registos que caem no disco para suportes de dados rápidos ou rodo-os firmemente para que as E/S não tornem a aplicação mais lenta.
Cache de objetos: usando Redis/Memcached corretamente
Escolho o Redis pela persistência e por funcionalidades como as diretrizes de fluxo. memória máxima para que as teclas de atalho não sejam deslocadas, e definir uma política de despejo adequada (por exemplo, allkeys-lru). Serializadores como o igbinary economizam RAM, TTLs curtos em transientes voláteis reduzem a rotatividade. Importante: A camada de cache de objectos deve aliviar a BD - se o rácio de acertos continuar baixo, analiso a distribuição das chaves e igualo os caminhos do código até os acertos aumentarem.
Eliminar rapidamente fontes comuns de erro
Muitos timeouts são causados por alguns gatilhos - eu verifico primeiro Cron, Heartbeat e Pesquisa. Mudo o WP-Cron para o cron do sistema, estrangulo fortemente a API Heartbeat e substituo as dispendiosas listas de backend por cache do lado do servidor. Os plugins problemáticos são removidos ou substituídos por alternativas mais leves, especialmente se causarem erros externos sempre que uma página é chamada. APIs contacto. No .htaccess, removo loops de redireccionamento duplicados e corrijo manipuladores de PHP incorrectos que duplicam processos. Abrandei os bots e os scrapers com limites de taxa e um CDN a montante para que os utilizadores reais não tenham de esperar.
Resumo para uma aplicação rápida
Eu remedeio um Tempo limite numa ordem fixa: medir a causa, aumentar os limites, ativar a cache, simplificar a base de dados, aumentar o alojamento. Uma estratégia clara de worker e de cache é crucial para que os pedidos não concorram por recursos. Com uma cache de página inteira, uma cache de objectos e activos WebP limpos, a carga do servidor é imediatamente reduzida, muitas vezes várias vezes. Se isso não for suficiente, mais CPU/RAM, armazenamento NVMe mais rápido e parâmetros PHP FPM bem definidos trarão o necessário Reserva. Os testes de carga e a monitorização fecham o ciclo, porque só as medições repetidas garantem o desempenho com tráfego real.
