WordPressin cron-järjestelmä eli WP-Cron vastaa monista taustalla tapahtuvista tehtävistä kuten ajastetuista julkaisuista, välimuistin siivouksesta, sähköposteista, webhookeista ja WooCommerce-prosesseista. Ongelma on se, että WP-Cron ei ole oikea järjestelmätason cron, vaan pseudo-cron, joka käynnistyy käyttäjäliikenteen perusteella.
WordPress tarkistaa jokaisen sivupyynnön yhteydessä onko ajastettuja tehtäviä suoritettavana....
WP-Cron ei ole jatkuvasti käynnissä oleva daemon....
Paras käytäntö tuotannossa:...
Hyödyt:...
WordPress tallentaa cron-eventit tietokantaan....
Suosittu plugin:...
WooCommerce käyttää usein Action Scheduleria....
Suurissa kaupoissa ongelmia:...
WP-CLI:...
Cronit epäonnistuvat usein hiljaisesti....
Pitkät cronit aiheuttavat helposti:...
Huono:...
Isoissa järjestelmissä:...
Korkean liikenteen sivustoissa sama cron voi käynnistyä useita kertoja....
Voit mitata cronin keston:...
New Relic on erittäin hyödyllinen....
Yksi yleisimmistä ongelmista:...
Kaikki API:t eivät vastaa aina onnistuneesti....
Esimerkki:...
Vanhoja cron-eventtejä voi jäädä tietokantaan....
Esimerkiksi:...
Huonosti optimoidut cronit voivat nostaa:...
Tyypillisiä ongelmia:...
Hyvä tuotantoympäristö:...
WordPressin cron-järjestelmä toimii hyvin pienissä ympäristöissä, mutta suuremmissa projekteissa se tarvitsee kunnollisen monitoroinnin ja hallinnan. Oikea server-cron, hyvä logging, queue-ajattelu ja virheiden seuranta tekevät järjestelmästä...
Tämä aiheuttaa helposti tilanteita joissa cron-tehtävät:
- eivät käynnisty ajallaan
- kasaantuvat jonoon
- epäonnistuvat hiljaisesti
- kuormittavat palvelinta
- aiheuttavat timeoutteja
Siksi monitorointi ja virheiden hallinta ovat erittäin tärkeitä erityisesti suuremmissa WordPress-ympäristöissä.
Miten WP-Cron toimii
WordPress tarkistaa jokaisen sivupyynnön yhteydessä onko ajastettuja tehtäviä suoritettavana.
Keskeinen tiedosto:
wp-cron.php
Jos tehtäviä löytyy:
- WordPress käynnistää cron-ajon
- tehtävät suoritetaan PHP-prosessissa
- hookit ajetaan järjestyksessä
Miksi WP-Cron aiheuttaa ongelmia
WP-Cron ei ole jatkuvasti käynnissä oleva daemon.
Ongelmat:
- ei liikennettä → cron ei käynnisty
- korkea liikenne → useita rinnakkaisia cron-prosesseja
- hitaat tehtävät → timeoutit
- epäonnistumiset jäävät huomaamatta
WooCommerce-sivustoissa tämä näkyy erityisen nopeasti.
Poista pseudo-cron käytöstä
Paras käytäntö tuotannossa:
define('DISABLE_WP_CRON', true);
Tämän jälkeen käytetään oikeaa server-cronia.
Linux cron:
*/5 * * * * php /path/to/public_html/wp-cron.php
Tai curl-pohjainen ratkaisu:
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1
Miksi oikea cron on parempi
Hyödyt:
- ennustettava suoritus
- ei riippuvuutta liikenteestä
- vähemmän race conditioneita
- parempi skaalautuvuus
- helpompi monitorointi
WP-Cron tapahtumien tarkastelu
WordPress tallentaa cron-eventit tietokantaan.
Näet ne esimerkiksi WP-CLI:llä:
wp cron event list
Tämä näyttää:
- hookit
- seuraavan ajon
- recurrence-asetukset
WP Crontrol monitorointiin
Suosittu plugin:
- WP Crontrol
Mahdollistaa:
- cronien selaamisen
- manuaalisen ajon
- virheiden tarkastelun
- ajastusten hallinnan
Hyödyllinen erityisesti kehityksessä.
Action Scheduler WooCommercessa
WooCommerce käyttää usein Action Scheduleria.
Tyypillisiä tehtäviä:
- sähköpostit
- webhookit
- subscription renewals
- API syncit
- taustaprosessit
Taulut:
actionscheduler_actions
actionscheduler_logs
Action Schedulerin ongelmat
Suurissa kaupoissa ongelmia:
- tuhansia pending-tehtäviä
- timeoutit
- failed-actions
- duplicate jobs
- korkea CPU-kuorma
Näitä pitää monitoroida aktiivisesti.
Failed cronien tunnistaminen
WP-CLI:
wp cron event run --due-now
Tämä auttaa tunnistamaan:
- rikkoutuneet hookit
- timeoutit
- fatal errorit
Error logging käyttöön
Cronit epäonnistuvat usein hiljaisesti.
Ota käyttöön:
define('WP_DEBUG_LOG', true);
Ja logita omat cronit:
error_log('Cron executed');
Timeout-ongelmat
Pitkät cronit aiheuttavat helposti:
- memory exhausted
- max execution time
- PHP worker blockage
Ratkaisuja:
- pilko tehtävät pienempiin osiin
- käytä queue-järjestelmää
- batch processing
Batch processing käytännössä
Huono:
foreach ($orders as $order) {
process_order($order);
}
Parempi:
$batch = array_slice($orders, 0, 50);
Queue-pohjainen arkkitehtuuri
Isoissa järjestelmissä:
- Redis queues
- RabbitMQ
- SQS
- background workers
ovat paljon vakaampia kuin pelkkä WP-Cron.
Cron race conditions
Korkean liikenteen sivustoissa sama cron voi käynnistyä useita kertoja.
Ratkaisu:
if (get_transient('my_cron_lock')) {
return;
}
set_transient('my_cron_lock', true, 300);
Lopuksi:
delete_transient('my_cron_lock');
Cronien suoritusajan mittaus
Voit mitata cronin keston:
$start = microtime(true);
run_task();
$time = microtime(true) - $start;
error_log($time);
Tämä auttaa löytämään hitaat tehtävät.
New Relic ja cron monitorointi
New Relic on erittäin hyödyllinen.
Näet:
- hitaat cronit
- memory usage
- queryt
- external API latencyt
Ulkoiset API-kutsut cronissa
Yksi yleisimmistä ongelmista:
wp_remote_get()
ilman timeoutia.
Parempi:
wp_remote_get($url, [
'timeout' => 10
]);
Retry-logiikka
Kaikki API:t eivät vastaa aina onnistuneesti.
Hyvä ratkaisu:
- exponential backoff
- retry limit
- failed queue
Monitorointi Slackiin tai sähköpostiin
Esimerkki:
wp_mail(
'admin@example.com',
'Cron failed',
'Task failed'
);
Tai webhook Slackiin.
Cron cleanup
Vanhoja cron-eventtejä voi jäädä tietokantaan.
Erityisesti:
- poistettujen pluginien hookit
- WooCommerce failed actions
- vanhat transientit
Kannattaa siivota säännöllisesti.
WP-CLI automatisointi
Esimerkiksi:
wp cron event run --all
Voidaan yhdistää CI/CD- tai monitorointiskripteihin.
Suorituskyky ja cronit
Huonosti optimoidut cronit voivat nostaa:
- CPU-kuormaa
- memory usagea
- TTFB:tä
- PHP worker käyttöä
Cronit ovat usein “näkymätön pullonkaula”.
Yleisimmät virheet
Tyypillisiä ongelmia:
- pseudo-cron jätetään tuotantoon
- ei loggingia
- ei lock-mekanismia
- liian isot batchit
- API timeoutit puuttuvat
- failed actions kasaantuvat
- WooCommerce queue jää monitoroimatta
Paras käytäntö
Hyvä tuotantoympäristö:
- DISABLE_WP_CRON käytössä
- server-level cron
- Redis Object Cache
- logging aktiivinen
- monitorointi käytössä
- batch processing
- retry-logiikka
- queue-lockit
Yhteenveto
WordPressin cron-järjestelmä toimii hyvin pienissä ympäristöissä, mutta suuremmissa projekteissa se tarvitsee kunnollisen monitoroinnin ja hallinnan. Oikea server-cron, hyvä logging, queue-ajattelu ja virheiden seuranta tekevät järjestelmästä huomattavasti vakaamman ja skaalautuvamman.
Cron-tehtävät ovat usein kriittinen osa WooCommercea, integraatioita ja automaatioita, joten niiden toimintaa ei kannata jättää oletusasetusten varaan.