Vai al contenuto 
Un numero elevato di visitatori genera picchi di carico in pochi secondi: se il worker PHP, il database e la cache non funzionano, la chiamata alla pagina termina nell'intervallo di tempo tra la fine del mese e la fine del mese. Timeout di WordPress. Vi mostrerò perché le richieste si bloccano, come potete individuare la causa e utilizzare impostazioni e aggiornamenti specifici per eliminare i timeout sotto carico - in modo permanente. performante.
Punti centrali
- CauseLavoratori PHP sovraccarichi, database lento, cache mancante
- DiagnosiLog del server, test di carico, controlli dei plug-in e analisi delle query
- ImmediatamenteAumentare i limiti di PHP, modificare WP-Cron, riparare .htaccess
- OttimizzazioneCaching, cache degli oggetti, ottimizzazione delle immagini e delle risorse, CDN
- Scala: hosting più forte, più lavoratori PHP, adeguamento dei limiti di connessione
Perché un carico elevato provoca il timeout
Un aumento delle richieste simultanee consuma prima lo spazio libero. CPU, poi l'I/O e i blocchi del database si bloccano e i tempi di risposta aumentano. Spesso vedo i worker PHP pieni mentre le nuove richieste rimangono in coda e poi si trasformano in un errore 504 o 502 - un classico Timeout. L'hosting condiviso aggrava la situazione perché si condividono le risorse con altri progetti e i picchi si sommano. Ancora più insidioso: query di database non ottimizzate su wp_options o post con revisioni che costano secondi. Se a ciò si aggiunge la mancanza di una cache della pagina, alla fine non c'è più tempo a disposizione per il sito.
502 vs. 504: interpretazione corretta delle immagini di errore
Prima di scattare, distinguo i sintomi: A 502 Gateway non valido spesso indica un processo di backend PHP in crash o irraggiungibile (riavviare FPM, controllare i limiti). A 504 Timeout gateway segnala che l'upstream (PHP-FPM) sta rispondendo troppo lentamente, di solito a causa di lavoratori bloccati, query lente o troppo strette. read_timeout-al proxy. Se entrambi gli errori si verificano alternativamente, l'attenzione si concentra sulla lunghezza delle code e sui limiti delle connessioni: il proxy può ancora accettare nuove connessioni, ma FPM non accetta più lavori o li rifiuta a causa dell'eccessivo riempimento.
Trovare la causa: Diagnosi in pochi minuti
Inizio con i log degli errori e degli accessi, perché è da lì che riconosco i picchi di Richieste e lunghi tempi di esecuzione. Poi controllo la CPU, la RAM, l'I/O e i processi PHP attivi, per verificare se i worker sono al limite o se dominano le query lente. A livello di app, attivo il log di debug per visualizzare le azioni e gli hook lunghi e identificare le query difettose. Plugins per isolarla. Quindi disattivo tutte le estensioni e le attivo singolarmente fino a determinare il fattore scatenante. Infine, simulo il carico per vedere quando inizia a fallire e se la cache e la cache degli oggetti hanno effetto.
Misure immediate che hanno un effetto evidente
Per prima cosa aumento il tempo di esecuzione e la memoria in modo che l'esecuzione di Processi non morire in caso di timeout: in wp-config.php con set_time_limit(300); e per define('WP_MEMORY_LIMIT','512M');. Se consentito, ho impostato in .htaccess php_value max_execution_time 300 e php_value limite_di_memoria 512M per saperne di più Buffer. Poi disattivo WP-Cron tramite definire('DISABLE_WP_CRON', true); e ho impostato un vero cron di sistema in modo che le richieste di pagine non attivino l'esecuzione di cron. Se il file è corrotto, il dialogo permalink genera un nuovo .htaccess. Infine, svuoto tutte le cache e controllo nella finestra in incognito se il TTFB crolla o rimane stabile.
Configurare in modo specifico i timeout del server web e del proxy
Mi assicuro che la catena di server web e PHP-FPM abbia finestre temporali sufficienti, ma non generi blocchi inattivi. Per NGINX regolo fastcgi_read_timeout, fastcgi_connect_timeout e send_timeout moderatamente verso l'alto (ad esempio 60-120 s), mentre keepalive_timeout rimane piuttosto breve per non occupare gli slot. Dietro un reverse proxy (bilanciatore di carico) ci sono proxy_read_timeout e timeout_connessione_proxy Entrambi devono corrispondere all'FPM e al budget dell'applicazione. In Apache limito KeepAliveTimeout (2-5 s) e aumentare Lavoratori MaxRichiesta solo se le riserve di RAM sono sufficienti per i processi aggiuntivi. La regola è: i timeout devono essere sufficientemente ampi, ma la durata e il numero di connessioni devono essere controllati in modo da non creare connessioni zombie.
Impostare correttamente PHP-FPM, i processi e i limiti
I time-out si verificano spesso perché sono in esecuzione troppo pochi PHP worker o perché sono bloccati per troppo tempo: qui vi aiuto a decidere PHP-FPM tramite pm=dynamic/ondemand e limiti ragionevoli. Un valore di partenza approssimativo per pm.max_childrenLa RAM disponibile per PHP divisa per la dimensione media dei processi, quindi prevedere una riserva di 20-30% in modo che il server possa respirare. pm.max_requests impedisce le perdite di memoria e pm.process_idle_timeout riduce i costi di inattività se il carico oscilla. Io attivo rigorosamente Opcache, in modo che l'interprete non si ricompili continuamente e il TTFB si riduca in modo significativo. Se volete approfondire l'argomento, potete trovare le pratiche Impostazioni di PHP-FPM, che uso come base prima di scalare o adattare il tema a NGINX/Apache.
Apache/NGINX/LiteSpeed: Modelli di lavoro e keep-alive
Ho scelto il modello di worker che corrisponde al profilo di traffico: Apache con mpm_evento scala meglio di prefork e si armonizza con FPM. NGINX beneficia di alcuni processi_lavoratori (auto) e alta connessioni_lavoratore, per servire molti client simultanei. LiteSpeed/LSAPI lega PHP in modo efficiente, ma richiede Max-Conn personalizzati sul lato PHP. Mantenere in vita Lo mantengo attivo, ma breve: timeout brevi e limitati. keepalive_requests evitare che i client inattivi blocchino gli slot. Ciò si rivela vantaggioso con HTTP/2 e HTTP/3, in quanto diverse risorse vengono eseguite su un'unica connessione e l'overhead è ridotto.
Semplificate e velocizzate il vostro database
Il freno più comune si trova nel Banca datirevisioni gonfiate, transitori vecchi e un carico eccessivo di autoload in wp_options. Faccio regolarmente ordine, riduco le revisioni, cancello i transitori scaduti e mantengo autoload='yes' piccoli, in modo che WordPress non carichi centinaia di kilobyte all'avvio. Ottimizzo le tabelle utilizzando lo strumento DB e controllo che non ci siano Indici per le condizioni WHERE frequenti. Per i dati multimediali di grandi dimensioni, mi affido all'offloading o a query di metadati efficienti per evitare che le JOIN esplodano. Se necessario, sollevo anche max_allowed_packet e utilizzare una cache di oggetti (Redis/Memcached), che riduce notevolmente il carico degli accessi in lettura.
Parametri MySQL/InnoDB e analisi lenta delle query
Attivo il Registri delle query lenti temporaneo (piccolo tempo_della_query-ad esempio 0,2-0,5 s) per rendere visibili i valori anomali. Per InnoDB ho dimensionato innodb_buffer_pool_size (50-70% della DB-RAM) in modo che i dati a caldo vengano memorizzati. innodb_log_file_size e innodb_flush_log_at_trx_commit Mi regolo in base ai requisiti di coerenza. Un SSD/NVMetmpdir accelera i grandi tipi, e credo che max_connessioni in equilibrio con il numero di worker PHP e con il pooling delle connessioni, in modo che il DB non sia costretto a fare thrash. Importante: evitare le trappole di autocommit e le transazioni lunghe, perché allungano i lock e rallentano intere catene di pagine.
Caching e CDN: togliere il carico all'applicazione
La cache della pagina fornisce l'HTML senza toccare PHP o il database: questo è il vantaggio maggiore durante i picchi di traffico. Leva. Imposto una cache a pagina intera con un TTL lungo, distinguo tra utenti loggati e ospiti e attivo „stale-while-revalidate“ in modo che le pagine rimangano veloci anche durante le ricostruzioni. La cache degli oggetti accelera le ripetute Domande, mentre un CDN fornisce risorse statiche vicino all'utente e riduce in modo massiccio il carico di origine. Converto le immagini in WebP, attivo il caricamento pigro e lo combino con HTTP/2 o HTTP/3 in modo che molti file fluiscano in parallelo. Questa guida Cache a pagina intera, a cui do sempre la priorità durante i picchi di carico.
Strategia per la cache: chiavi, varianti e protezione contro la fuga di notizie
Definisco chiavi di cache precoci e stabili: percorso, host, cookie rilevanti (il minor numero possibile) e tipo di dispositivo. Impostiamo deliberatamente i cookie che personalizzano (ad es. carrello della spesa, valuta) come Variare oppure li aggiro con la cache frammentata. Contro Cache stampede aiuta „stale-while-revalidate“, microcaching (1-10 s) sul server web e preriscaldamento dei percorsi critici prima delle campagne. Mi occupo della pulizia InvalidazioneEliminare specificamente quando il contenuto viene pubblicato, invece di svuotare l'intera cache. In questo modo si mantengono alti i tassi di successo e costanti i tempi di risposta, anche a pieno carico.
Confronto tra hosting e aggiornamenti sensati
Ad un certo punto, si raggiunge il punto in cui i limiti del pacchetto entrano in vigore - allora il sito ha bisogno di più Risorse invece di effettuare la messa a punto. Quando le cose si fanno davvero impegnative, abbandono gli ambienti condivisi e passo a offerte gestite con CPU/RAM dedicate o a un VPS con NGINX/LiteSpeed e storage NVMe. IOPS veloci, un numero sufficiente di PHP worker e il più recente PHP 8+ con Opcache. Per i picchi ricorrenti, l'autoscaling aiuta a scalare il worker e il database senza intervento manuale. La seguente panoramica mostra le opzioni più comuni e le loro caratteristiche.
| Luogo | Fornitore/Tipo | Spessore del nucleo | Consigliato per |
|---|---|---|---|
| 1 | webhoster.de (gestito) | Autoscaling, SSD NVMe, CPU/RAM elevata, WP gestito | Traffico elevato, scalabilità |
| 2 | Hosting WP gestito | Caching integrato, PHP worker ottimizzato | Carico medio |
| 3 | VPS con NGINX/LiteSpeed | IOPS elevati, risorse dedicate | Siti sofisticati |
Scalabilità, limiti di connessione e lavoratori PHP
Il parallelismo si interrompe se il server web, PHP-FPM o il database sono troppo stretti. Limiti set. I equilibrio pm.max_children con la dimensione reale del processo, regolare i keepalive del server web e controllare i pool di connessioni MySQL. Tra l'altro, un numero eccessivo di lavoratori può esaurire la RAM e intasare l'I/O. Procedo quindi per gradi e misuro. Se si verificano errori 500 o 504 sotto carico, controllo insieme i limiti di connessione, i timeout e la lunghezza delle code. Una spiegazione compatta delle tipiche trappole dei limiti si trova in questo articolo su Limiti di connessione, che spesso mi fa risparmiare minuti nell'analisi della causa.
Caching efficiente di WooCommerce e delle aree dinamiche
Il commercio elettronico sfida la strategia di cache: Ho messo in cache completamente le pagine delle categorie, le pagine dei prodotti e i contenuti del CMS, mentre il carrello, il checkout e „Il mio account“ sono specificamente esclusi dalla cache. Frammenti di carrello e banner personalizzati ricaricando o frammentando piccole parti dinamiche tramite JavaScript. I cookie come quelli relativi alla valuta, al paese o alla sessione finiscono solo nel file Variare, quando è inevitabile; altrimenti distruggono il tasso di successo. Riscaldo le azioni pianificate (ad esempio, le vendite) in modo che nessuna cache fredda si riscaldi all'inizio. Limito gli endpoint Ajax e REST dell'amministrazione raggruppando le query, mettendo in cache i risultati e limitando il polling.
Test di carico, monitoraggio e avvisi
Non mi affido al sentimento, dimostro gli effetti con Misure. Prima delle campagne, simulo ondate di visitatori, aumento gradualmente la concurrency e verifico a quale carico aumentano il TTFB e il tasso di errore. Gli strumenti APM mi mostrano le transazioni, le query e le chiamate esterne più lente: è proprio qui che faccio leva. Gli avvisi su CPU, RAM, tasso di 5xx e tempi di risposta mi avvertono per tempo, in modo da poter essere preparato prima dell'evento reale. Fallimento reagire. Ripeto poi il test con la cache attivata per assicurarmi che le ottimizzazioni funzionino a pieno carico.
Proteggere i servizi esterni e le richieste HTTP
Molti timeout derivano dal blocco delle chiamate HTTP nei temi/plugin. Ho impostato finestre temporali strette per wp_remote_get()/wp_remote_post() (timeout di connessione/lettura), creare dei fallback e spostare le sincronizzazioni costose in lavori in background. Controllo la risoluzione DNS e l'handshake SSL separatamente: risolutori o catene di certificati difettosi rallentano notevolmente le cose. Metto in cache i risultati ricorrenti a livello locale, in modo che i malfunzionamenti delle API esterne non si ripercuotano sul sito. Principio: l'I/O esterno non deve mai dominare il tempo di esecuzione della richiesta.
Sicurezza, traffico bot e regole WAF
Proteggo l'applicazione dal traffico inutile: Limiti di velocità su login, XML-RPC e endpoint di ricerca, regole severe contro gli scrapers e i bad bots e una strozzatura per i crawler aggressivi. 429/503 con Riprova dopo aiutano a mantenere la capacità libera per gli utenti reali. Un WAF upstream smista i picchi del Layer 7 e blocca i vettori di attacco noti prima che abbiano un impatto su PHP/DB. Per i media, attivo una cache sensibile (ETag/Last-Modified) in modo che le chiamate ripetute non generino quasi alcun costo del server.
Limiti del sistema e messa a punto del sistema operativo
Se le connessioni vengono improvvisamente rifiutate sotto carico, guardo ai parametri del sistema operativo: fs.file-max e i descrittori aperti per il server web/DB, net.core.somaxconn e net.ipv4.ip_local_port_range per molte prese simultanee. Una troppo piccola arretrato o aggressivo tcp_fin_timeout crea colli di bottiglia. Sposto i registri che si bloccano sul disco su supporti dati veloci o li ruoto strettamente in modo che l'I/O non rallenti l'applicazione.
Cache degli oggetti: usare correttamente Redis/Memcached
Ho scelto Redis per la persistenza e per funzioni come le linee guida del flusso. maxmemory in modo che i tasti di scelta rapida non vengano spostati e impostare una politica di sfratto adeguata (ad esempio, allkeys-lru). Serializzatori come igbinary fanno risparmiare RAM, brevi TTL sui transitori volatili riducono il churn. Importante: il livello di cache degli oggetti deve alleggerire il DB - se il rapporto di hit rimane basso, analizzo la distribuzione delle chiavi e equalizzo i percorsi del codice finché gli hit non aumentano.
Eliminare rapidamente le fonti di errore più comuni
Molti timeout sono causati da alcuni fattori scatenanti. Cron, Heartbeat e Ricerca. Sostituisco WP-Cron con Cron di sistema, limito fortemente l'API Heartbeat e sostituisco i costosi elenchi di backend con la cache sul lato server. I plugin problematici vengono rimossi o sostituiti con alternative più leggere, soprattutto se causano errori esterni ogni volta che viene richiamata una pagina. API contatto. In .htaccess, rimuovo i loop di reindirizzamento duplicati e correggo i gestori PHP errati che duplicano i processi. Rallento i bot e gli scrapers con limiti di velocità e un CDN upstream, in modo che gli utenti reali non debbano aspettare.
Sintesi per una rapida implementazione
Rimedio a un'imminente Timeout in un ordine fisso: misurare la causa, aumentare i limiti, attivare la cache, snellire il database, aumentare l'hosting. Una chiara strategia di worker e cache è fondamentale per evitare che le richieste competano per le risorse. Con una cache a pagina intera pulita, una cache degli oggetti e degli asset WebP, il carico del server si riduce immediatamente, spesso di molte volte. Se questo non è sufficiente, una maggiore quantità di CPU/RAM, uno storage NVMe più veloce e parametri PHP FPM ben impostati porteranno il necessario Riserva. I test di carico e il monitoraggio chiudono il cerchio, perché solo misure ripetute garantiscono le prestazioni in condizioni di traffico reale.
