WordPress Cron kokonaisuutena
WordPress Cron, eli wp-cron, on yksi WordPressin eniten väärinymmärretyistä järjestelmistä. Nimestään huolimatta se ei ole oikea cron siinä mielessä kuin käyttöjärjestelmät sen tuntevat. Se on HTTP-pyyntöihin sidottu ajastusmekanismi, joka toimii vain silloin kun sivustolla on liikennettä. Tämä yksi suunnitteluratkaisu selittää valtaosan sekä suorituskyky- että luotettavuusongelmista, joita wp-cron aiheuttaa tuotantoympäristöissä.
Wp-cron on rakennettu helppokäyttöisyyttä varten, ei suurta mittakaavaa varten. Se on erinomainen ratkaisu pienille sivustoille ja jaetuille hosting-ympäristöille, mutta muuttuu arkkitehtoniseksi riskiksi heti kun WordPressistä tulee liiketoimintakriittinen järjestelmä.
Miten WordPress Cron oikeasti toimii
Ei taustaprosessi vaan sivulatauksen sivutuote
Wp-cron ei pyöri taustalla. Kun käyttäjä tai botti tekee HTTP-pyynnön WordPressiin, WordPress tarkistaa, onko ajastettuja tehtäviä, joiden suoritusajankohta on mennyt. Jos on, WordPress käynnistää wp-cron.php:n samassa tai erillisessä HTTP-kutsussa.
Tämä tarkoittaa kahta asiaa:
-
jos sivustolla ei ole liikennettä, cron ei koskaan aja
-
jos sivustolla on paljon liikennettä, cron voi yrittää ajaa liian usein
Cron ei ole ajastettu, se on opportunistinen.
Pseudokellon ongelma
Wp-cron luottaa WordPressin omaan aikakäsitykseen, ei käyttöjärjestelmän kelloon. Jos sivuston aikavyöhyke, palvelimen aika tai PHP:n time()-funktio ovat epäsynkassa, ajastukset voivat käyttäytyä oudosti. Tämä näkyy erityisesti pitkissä väleissä ajettavissa tehtävissä, kuten päivittäisissä raporteissa tai varmuuskopioissa.
Suorituskykyongelmat wp-cronissa
Cron ajetaan väärässä paikassa
Yksi suurimmista ongelmista on se, että wp-cron ajetaan käyttäjän HTTP-pyynnön yhteydessä. Tämä tarkoittaa, että:
-
PHP-prosessi varataan cron-tehtäville
-
sivulataus voi hidastua
-
käyttäjä maksaa viiveen
Vaikka wp-cron usein yrittää ajaa erillisessä pyynnössä, tämä ei ole taattua. Kuormassa tai rajoitetuissa ympäristöissä cron voi päätyä samaan prosessiin kuin sivulataus.
Raskaat cron-tehtävät
WordPressissä cron-tehtävät voivat tehdä lähes mitä tahansa: HTTP-kutsuja, tietokantapäivityksiä, kuvankäsittelyä, raportointia. Wp-cron ei kuitenkaan rajoita tehtävien kestoa tai resurssien käyttöä.
Yksi huonosti kirjoitettu cron-hook voi:
-
lukita PHP-prosessin sekunneiksi tai minuuteiksi
-
kasvattaa muistinkäyttöä
-
estää muiden cron-tehtävien ajon
Koska kaikki tapahtuu saman sovelluskerroksen sisällä, virhe leviää helposti.
Cron-ruuhkat
Jos wp-cron ei pääse ajamaan pitkään aikaan, tehtävät kasaantuvat. Kun seuraava HTTP-pyyntö lopulta käynnistää cronin, WordPress yrittää ajaa kaikki myöhässä olevat tehtävät kerralla.
Tämä aiheuttaa piikkikuormia, jotka näkyvät:
-
korkeana CPU-käyttönä
-
hitaina vasteaikoina
-
aikakatkaisuina
-
satunnaisina virheinä
Tämä on klassinen “hiljaisen ajan kostautuminen”.
Luotettavuusongelmat
Liikenne-ehtoisuus
Wp-cron ei ole luotettava ajastin vähäliikenteisillä sivustoilla. Jos sivustolla ei ole kävijöitä, cron ei aja. Tämä on ongelma erityisesti:
-
verkkokaupoissa (tilaus- ja varastopäivitykset)
-
jäsenyyssivustoilla
-
varmuuskopioissa
-
ajastetuissa sähköposteissa
Tehtävä voi olla määritelty ajettavaksi “kello 03:00”, mutta se ajetaan vasta seuraavana päivänä, kun joku sattuu vierailemaan sivustolla.
Epädeterministinen ajo
Wp-cron ei takaa tarkkaa ajoaikaa. Tehtävä ajetaan “jossain vaiheessa sen jälkeen”, ei “täsmälleen silloin”. Tämä tekee siitä huonon valinnan tehtäville, joissa ajoaika on kriittinen.
Luotettavuus kärsii erityisesti silloin, kun useampi järjestelmä olettaa cronin toimivan kellontarkasti.
Virheet katoavat hiljaa
Jos cron-tehtävä epäonnistuu, WordPress ei oletuksena ilmoita siitä kenellekään. Ei hälytystä, ei lokia, ei varoitusta adminiin. Tehtävä voi epäonnistua viikkoja ennen kuin joku huomaa seurauksen.
Tämä on vaarallista tuotantoympäristöissä, joissa cron hoitaa liiketoimintakriittisiä tehtäviä.
wp-cron ja hosting-ympäristöt
Jaettu hosting
Wp-cron on alun perin suunniteltu jaettua hostingia varten, jossa oikeaa cron-ajastinta ei aina ole saatavilla. Tässä kontekstissa se on edelleen perusteltu kompromissi.
Ongelma syntyy, kun sama malli siirretään VPS- ja pilviympäristöihin, joissa oikea cron on saatavilla mutta sitä ei hyödynnetä.
PHP-FPM ja prosessipoolit
PHP-FPM-ympäristössä wp-cron kilpailee samoista prosesseista kuin käyttäjäliikenne. Jos cron-tehtävät ovat raskaita, ne syövät kapasiteettia sivulatauksilta.
Tämä näkyy usein epäsuorasti: sivusto hidastuu “satunnaisesti”, vaikka liikennemäärä ei ole kasvanut.
Yleiset virheet wp-cronin käytössä
Liian tiheät ajastukset
Moni lisäosa rekisteröi cron-tehtäviä, jotka ajavat minuutin tai viiden minuutin välein, vaikka tarve olisi tuntitasolla. Tämä kasvattaa cronin kokonaiskuormaa merkittävästi.
Wp-cron ei ole suunniteltu korkeataajuiseksi ajastimeksi.
Ulkoiset HTTP-kutsut cronissa
Cron-tehtävä, joka tekee ulkoisen HTTP-kutsun ilman timeout- ja virheenkäsittelyä, on klassinen suorituskykyriski. Jos ulkoinen rajapinta hidastuu, koko cron jumittuu.
Yksi epäluotettava API voi lamauttaa koko ajastusjärjestelmän.
Ei lukituksia
Wp-cron ei oletuksena estä saman tehtävän rinnakkaista ajoa. Jos cron käynnistyy useasta pyynnöstä yhtä aikaa, sama tehtävä voi ajaa päällekkäin.
Tämä voi aiheuttaa:
-
tuplatoimintoja
-
tietokantavirheitä
-
datan korruptoitumista
Ratkaisut ja parannusmallit
Oikea cron käyttöjärjestelmätasolla
Yleisin ja suositeltavin ratkaisu on poistaa wp-cron käytöstä ja ajaa se käyttöjärjestelmän cronilla. Tämä muuttaa wp-cronin luotettavaksi ajastimeksi, joka ei riipu liikenteestä.
Arkkitehtonisesti tämä on suuri parannus: ajo on ennustettavaa, kuorma hallittua ja virheet helpommin havaittavissa.
Tehtävien pilkkominen
Raskaat cron-tehtävät kannattaa pilkkoa pienemmiksi osiksi. Sen sijaan että yksi cron tekee kaiken, se voi vain käynnistää jonon tai tilakoneen, joka etenee askel kerrallaan.
Tämä vähentää piikkikuormaa ja parantaa virheensietoa.
Lokitus ja näkyvyys
Cron-tehtävät kuuluvat aina lokituksen piiriin. Ilman näkyvyyttä ei ole luotettavuutta. Lokit voivat olla kevyitä, mutta niiden on kerrottava:
-
milloin tehtävä ajettiin
-
kauanko se kesti
-
onnistuiko vai epäonnistuiko se
Wp-cron osana kokonaisarkkitehtuuria
Wp-cron ei ole “huono”. Se on kompromissi. Ongelmat syntyvät, kun sitä käytetään väärässä kontekstissa tai väärään tarkoitukseen.
Hyvä arkkitehtuuri tunnistaa wp-cronin rajat ja käyttää sitä vain siellä, missä sen malli on hyväksyttävä. Kun tehtävät muuttuvat kriittisiksi, ajastuksen täytyy irrota käyttäjäliikenteestä.
Lopuksi: ajastus on luottamuskysymys
Cron on järjestelmän sydämenlyönti. Jos siihen ei voi luottaa, koko järjestelmä muuttuu arvaamattomaksi. WordPressin wp-cron tarjoaa helpon alun, mutta ei kestävää loppuratkaisua vaativissa ympäristöissä.
Kun suorituskyky ja luotettavuus ovat tärkeitä, ajastus ei saa olla sivuvaikutus. Sen on oltava tietoinen, hallittu ja mitattu osa järjestelmäarkkitehtuuria.
