Vai al contenuto 
Cronjob di WordPress Quando le richieste di pagine bloccano lo scheduler interno, le cache intercettano le richieste o i limiti dell'hosting bloccano le attività più lunghe, il sistema fallisce sotto carico. Mostro le cause, le conseguenze e le soluzioni concrete per garantire l'esecuzione affidabile di attività quali aggiornamenti, backup e post programmati.
Punti centrali
Per cominciare, riassumerò gli aspetti più importanti in modo breve e chiaro, prima di entrare nel dettaglio e spiegare i passaggi specifici che utilizzo in modo produttivo. Identificazione del problema e Cause sono l'obiettivo di questo documento.
- MeccanicaWP-Cron si attiva sulle richieste di pagina invece che tramite il cron di sistema.
- CaricoIl traffico elevato e il „carico cron di wordpress“ generano timeout.
- CachingIl caching completo della CDN interrompe l'esecuzione di cron.
- LimitiI timeout di PHP e i budget di risorse annullano le attività.
- rimedioCron del server, intervalli di pulizia, registrazione e messa a punto.
WP-Cron spiegato brevemente: chiamata di pagina invece di servizio di sistema
Inizio con il Idea di baseWordPress controlla se le attività pianificate sono dovute a ogni richiesta di pagina e le lancia tramite una richiesta HTTP interna a wp-cron.php. Questo approccio compensa la mancanza di accesso ai cronici reali del server, ma crea una dipendenza dal file Traffico. Se una pagina non raggiunge quasi nessun visitatore, le attività vengono eseguite in ritardo o non vengono eseguite affatto. Se un CDN serve ogni richiesta dalla cache, PHP non viene caricato e WP-Cron rimane inattivo. Questo spiega perché le pubblicazioni programmate, i lavori di posta elettronica o i backup appaiono inaffidabili su alcune installazioni. Più i plugin registrano task aggiuntivi, più la coda diventa densa e più l'esecuzione diventa vulnerabile.
Perché i cronjob di carico stanno crollando
Se il flusso di visitatori aumenta, aumentano anche i controlli di cron e quindi la Carico del server. Un numero maggiore di richieste concorrenti compete per i lavoratori PHP, l'I/O e il database, causando il timeout delle chiamate cron. Le latenze si accumulano, i task si bloccano a vicenda e quelli lunghi escono dalla finestra temporale. Ho sempre affrontato questo problema in configurazioni produttive, come WP-Cron sui siti di produzione è spesso il fattore scatenante dei tempi di risposta lenti. In condizioni di carico elevato, i rallentamenti sono direttamente correlati all'uso eccessivo di trigger cron. Inoltre, i task scritti male aggravano la situazione perché avviano scansioni del database che assorbono ancora più risorse.
Limiti di hosting e loro conseguenze
Molti hoster utilizzano un Timeout PHP di 30-60 secondi; se un'attività supera questo limite, il sistema la termina bruscamente. Ciò riguarda i lavori di migrazione, le esportazioni di grandi dimensioni, l'elaborazione di immagini o le e-mail di massa. I limiti di memoria, i limiti di processo e i limiti di velocità per i loopback HTTP hanno un effetto simile. Se a questo si aggiunge un traffico ridotto, gli eventi dovuti si accumulano e vengono eseguiti in ritardo o non vengono eseguiti affatto. Pertanto, prima di modificare l'applicazione, controllo i limiti e i registri. Questo mi permette di riconoscere se l'ambiente sta causando colli di bottiglia o se i singoli task sono inefficienti.
Controllo rapido: cause, sintomi, soluzioni
La seguente panoramica mi aiuta a separare gli schemi di errore in modo strutturato e ad agire in modo mirato invece di sperimentare a casaccio. Ogni riga mostra un Causa, a visibile Sintomo e una misura immediata.
| Causa | Sintomo tipico | misura immediata |
|---|---|---|
| CDN/Proxy invertito serve 100% dalla cache | I contributi pianificati appaiono in ritardo | Disaccoppiare WP-Cron, impostare il cron del server reale |
| Timeout PHP (30-60 s) | Backup/esportazioni annullati | Aumentare il timeout, dividere l'attività in batch più piccoli |
| Troppi eventi cron | Latenza notevole in caso di picchi di traffico | Allungare gli intervalli, eliminare gli eventi non necessari |
| Query SQL inefficienti | L'utilizzo del database aumenta a dismisura | Impostazione degli indici, snellimento delle SELECT, caching |
| Sito web a basso traffico | Ore di ritardo | Eseguire cron di sistema ogni 15-60 minuti |
Integro il controllo con metriche reali provenienti dai log e dal monitoraggio per verificare le ipotesi e analizzare i risultati. Causa chiaramente. La tabella non sostituisce una misurazione, ma la incanala. Solo quando so se il timeout, la cache o il database sono limitanti, prendo le misure appropriate. Poi eseguo ripetuti test e verifico se ci sono effetti successivi. In questo modo, minimizzo lo sforzo e risolvo il problema in modo duraturo.
Migliori pratiche: Da WP-Cron a Server-Cron
Per prima cosa disattivo il trigger basato sulla pagina con DISABILITARE_WP_CRON in wp-config.php: define(‚DISABLE_WP_CRON‘, true);. Ho quindi impostato un vero e proprio cron di sistema che chiama wp-cron.php ciclicamente (ad esempio, tramite curl ogni 5 minuti per il traffico elevato, ogni ora per il traffico ridotto). Questo mi permette di disaccoppiare le esecuzioni dal flusso di visitatori e di attenuare i tempi di esecuzione di wp-cron. Carico. Allo stesso tempo, limito le chiamate simultanee in modo che non si verifichino tempeste di cron. Se prevedo dei picchi, aumento i lavoratori PHP e regolo i timeout. In particolare, in caso di traffico fluttuante, riduco Carico della CPU non uniforme e prevenire le reazioni a catena.
Intervalli, progettazione del compito e database
Verifico che ogni evento abbia il suo Intervallo e allungo le frequenze quando è giustificabile. Anziché ogni minuto, eseguo scansioni ogni ora o ogni giorno se l'attività non richiede un valore in tempo reale. Divido i lavori lunghi in piccoli lotti che vengono eseguiti in modo sicuro entro il timeout di PHP. Quando accedo ai database, imposto indici, riduco le colonne e mi astengo da scansioni complete. Metto in cache i dati più frequenti per intercettare le ripetizioni e ridurre al minimo la Banca dati dal lavoro non necessario. Questo riduce i tempi di esecuzione e le esecuzioni di cron rimangono calcolabili.
La diagnosi nella pratica: creare visibilità
Prima di ricostruire, voglio avere un sistema affidabile Dati diagnostici. Inizio con la visualizzazione dello stato di salute del sito WordPress e attivo il logging (WP_DEBUG_LOG) per rendere visibili gli errori PHP durante le chiamate cron. Poi elenco gli eventi scaduti e programmati e i loro tempi di esecuzione. Nei flussi di lavoro produttivi, utilizzo passaggi ripetibili:
- Attivare gli eventi dovuti tramite WP-CLI: wp cron event run -due-now
- Elenco degli eventi programmati: elenco eventi wp cron
- Impostare i propri punti di misurazione: Registrare l'ora di inizio/fine dell'attività, compresi i picchi di memoria.
- Controllare la pagina del database: Identificare le SELECT lunghe e aggiungere gli indici necessari
Se Site Health mostra „Esecuzione cron ritardata“, analizzo i log di accesso a wp-cron.php, i codici di risposta e la durata. 429/503 indicano limiti di velocità o di risorse, 401/403 indicano un blocco da parte di auth, firewall o WAF. Verifico se le richieste di loopback sono consentite internamente e se il nome host si risolve correttamente. Esamino anche l'opzione „cron“ di wp_options per valutare la dimensione e l'età della coda e identificare i ganci di funzione che falliscono ripetutamente.
Configurazione robusta del server cron: HTTP, WP-CLI e bloccaggio
Per gli ambienti produttivi, preferisco un Server cron tramite WP-CLI rispetto a una chiamata HTTP pura, perché avvio direttamente PHP e dipendo meno dal server web/proxy. Varianti esemplari che si sono dimostrate valide:
- Variabile HTTP, con budget di tempo e standstill: curl -sS https://domain.tld/wp-cron.php?doing_wp_cron=1 -max-time 55 -connect-timeout 5 >/dev/null
- WP-CLI direttamente: cd /path/to/installation && /usr/bin/wp cron event run -due-now -quiet
- Per evitare sovrapposizioni: flock -n /tmp/wp-cron.lock -c „/usr/bin/wp cron event run -due-now -quiet“.“
- Aumentare le risorse in modo specifico: php -d memory_limit=512M -d max_execution_time=300 wp-cli.phar cron event run -due-now
Uso flock per evitare gli avvii paralleli, che altrimenti porterebbero a esecuzioni duplicate e ad accessi al database concorrenti. Con diverse istanze (ad esempio Blue/Green, Container), permetto a un solo host di eseguire il cron e lo disattivo sugli altri. In questo modo evito condizioni di gara nella coda.
Loopback, auth e firewall: blocchi tipici
Se i cronjob rimangono in „pending“, il cronjob interno è spesso bloccato. Loopback. Verifico se Basic-Auth, restrizioni IP o un WAF impediscono le richieste a wp-cron.php. Nelle configurazioni sicure di staging, escludo wp-cron.php dall'autenticazione o permetto i loopback come eccezione. Se le chiamate HTTP esterne sono limitate, mi assicuro che il mio dominio non sia nella lista di blocco. ALTERNATE_WP_CRON può essere utile a breve termine, ma lo uso solo temporaneamente e lo rimuovo non appena è attivo un cron del server pulito.
Sovrapposizioni e idempotenza: rendere i compiti sicuri
Molti problemi sorgono a causa di Esecuzioni simultanee dello stesso task. Pertanto, installo i blocchi dei task (ad esempio, tramite transiente/opzione), controllo se un'esecuzione è già attiva prima di iniziare e termino la seconda chiamata in anticipo. Allo stesso tempo, rendo i task idempotenti: se una fase viene avviata due volte, non si verificano duplicazioni di e-mail, file o voci del DB. Per i lavori batch, salvo gli offset/marcatori per controllare le continuazioni in modo pulito e intercettare le ripetizioni. Questo riduce i danni conseguenti se un'esecuzione cron si interrompe inaspettatamente e viene riavviata successivamente.
Scalare: multiserver, container e multisito
In ambienti distribuiti opero esattamente uno Cron runner. Può essere un container worker separato o un nodo fisso che attiva tutti gli eventi dovuti tramite WP-CLI. I file system condivisi o le cache distribuite aiutano a mantenere gli stati e i lock coerenti tra le istanze. Nelle configurazioni multisito, controllo che Cron sia programmato correttamente per ogni rete di sottositi e che gli eventi di rete non inondino la coda globale in modo incontrollato. Mi assicuro anche che i fusi orari per ogni sito siano corretti, in modo che le pubblicazioni e le finestre temporali siano corrette.
Orari e fusi orari: evitare le „mancate scadenze“.
Un fattore sottovalutato sono Fusi orari e il cambio dell'ora legale. WordPress programma i post in base al fuso orario del sito, mentre i server spesso funzionano in UTC. Sincronizzo entrambi, controllo le impostazioni del fuso orario per le implementazioni e tengo conto dei cambiamenti di orario nel piano editoriale. Se si verifica un „Missed schedule“, verifico se il cronqueue è sovraccarico, se i ganci di pubblicazione falliscono o se l'ora del server si sta spostando. Un successivo „wp cron event run -due-now“ scarica la coda mentre io risolvo la causa effettiva (cache, timeout, fuso orario errato).
Sviluppo, staging e implementazioni
Negli ambienti di staging, disattivo le attività produttive (e-mail, esportazioni, webhook) in modo da non attivare azioni indesiderate. Imposto DISABLE_WP_CRON su true ed eseguo il mio cron di prova con intervalli lunghi. Prima del go-live, svuoto la coda, eseguo manualmente una volta le attività critiche e monitoro attentamente i log. Dopo le distribuzioni, un'esecuzione mirata „due-now“ attiva i nuovi ganci prima che le cache diventino nuovamente aggressive. In questo modo si evitano sorprese e si mantiene tranquilla la fase di introduzione.
Gestione degli errori, backoff e ripetizioni
I fallimenti capitano. Li pianifico Riprova con backoff: riprova solo dopo poco tempo, poi a distanza crescente. Documento i passaggi falliti con codici chiari e contesto (input, durata, memoria, SQL, codice HTTP). Dopo N tentativi falliti, contrassegno l'evento come „bloccato“ e mi informo tramite un avviso. Questa separazione evita i loop infiniti e mi dà il tempo di correggere la causa effettiva senza intasare la coda.
Strumenti: WP Crontrol e Action Scheduler
Per il quotidiano Controllo Utilizzo WP Crontrol per visualizzare, mettere in pausa o riprogrammare gli eventi direttamente in WordPress. Lo uso per riconoscere i ganci sospesi, le voci duplicate o gli intervalli errati. Per i processi di grandi dimensioni, utilizzo Action Scheduler, che suddivide le attività in piccole azioni e le registra in modo pulito. Se un'azione fallisce, la riavvio in modo mirato senza compromettere l'intera catena. In questo modo si riducono al minimo i picchi di lavoro, perché non si tratta di un monolite, bensì di Sottocompiti tatticamente. In questo modo si mantengono prevedibili le finestre di implementazione e manutenzione.
Hosting condiviso, caching e CDN
Negli ambienti condivisi, le chiamate cron si scontrano rapidamente con le chiamate Limiti, che non controllo direttamente. Se il CDN e la cache a pagina intera entrano in funzione, non una singola richiesta di pagina attiva WP-Cron. Lo aggiro con un cron di sistema e mi assicuro che le richieste di loopback siano accessibili. Se cron non si attiva in modo affidabile, controllo le politiche di rete, l'autenticazione di base e i firewall. Un test con una chiamata diretta a curl mostra se le richieste arrivano tecnicamente. Per informazioni di base e alternative, fare riferimento a Cronjob nell'hosting condiviso, perché i tipici ostacoli sono descritti in forma compatta.
Monitoraggio e manutenzione nella vita quotidiana
Conservo il Sito-Salute-Questo perché WordPress segnala visibilmente i ritardi nelle esecuzioni di cron. Scrivo anche dei log per analizzare statisticamente la durata, gli errori e le ripetizioni. In questo modo scopro anomalie che altrimenti passerebbero inosservate nell'attività quotidiana. Elimino o resetto gli eventi obsoleti o che falliscono definitivamente per mantenere la coda snella. Gli avvisi via e-mail o Slack mi informano se un lavoro fallisce più volte. Questo mi permette di intervenire prima che conseguenze come aggiornamenti mancati o e-mail non inviate causino danni.
Conclusione: il mio approccio in breve
Per prima cosa disaccoppio Cron dalle chiamate alla pagina, impostando un parametro Server cron e verifico l'accessibilità tramite curl. Poi ottimizzo gli intervalli, divido i task lunghi in batch e riduco il carico del database. Configuro la registrazione, osservo i percorsi di errore e regolo i limiti in modo che nessun task si blocchi al timeout. Se necessario, utilizzo Action Scheduler, che consente di suddividere in modo affidabile i processi lunghi in parti controllabili. Quindi misuro l'effetto e razionalizzo l'elenco di cron fino a quando la coda rimane pulita. In questo modo, le attività pianificate vengono eseguite in modo affidabile, anche se la coda Carico o cache funzionano in modo aggressivo.
