WordPress ja pitkäkestoiset prosessit kokonaisuutena
WordPress on rakennettu lyhytkestoisia HTTP-pyyntöjä varten. Se odottaa, että pyyntö alkaa, tekee työnsä ja päättyy nopeasti. Tässä maailmassa pitkäkestoiset prosessit ovat poikkeus, eivät sääntö. Silti moderni WordPress-sivusto tarvitsee taustaprosesseja enemmän kuin koskaan: synkronointeja, massapäivityksiä, integraatioita ja raportointia.
Ongelma ei ole se, ettei WordPress pysty taustatöihin. Ongelma on se, että ne tehdään usein väärällä tavalla.
Miksi pitkäkestoiset prosessit ovat ongelmallisia
HTTP ei ole job runner
HTTP-pyyntö:
-
on aikarajoitettu
-
voi katketa koska tahansa
-
ei takaa suorituksen loppuun asti
Kun WordPressissä yritetään:
-
käsitellä tuhansia rivejä yhdellä pyynnöllä
-
tehdä raskas API-synkronointi suoraan administa
-
ajaa import yhdellä napin painalluksella
lopputulos on usein timeout, muistivirhe tai puoliksi tehty työ.
Taustaprosessien perusmallit WordPressissä
WP-Cron
WP-Cron on WordPressin sisäänrakennettu ajastin. Se:
-
käynnistyy sivulatauksen yhteydessä
-
ei ole oikea cron
-
ei takaa ajotarkkuutta
WP-Cron toimii kevyissä tehtävissä, mutta:
-
ei sovellu pitkäkestoisiin prosesseihin
-
ei skaalaudu useisiin instansseihin ilman riskejä
Silti se on monen lisäosan perusta.
Eräajo ja pilkkominen
Yleisin ja toimivin malli WordPressissä on:
-
pilkkoa työ pieniin osiin
-
ajaa ne useissa requesteissa
-
tallentaa tila väliin
Yksi request tekee vähän työtä ja luovuttaa. Tämä malli:
-
kestää timeoutit
-
skaalautuu paremmin
-
on helpompi palauttaa virhetilanteissa
Background processing -kirjastot
Miksi niitä käytetään
Useat lisäosat käyttävät taustaprosessointikirjastoja, jotka:
-
hallitsevat jonoja
-
ajavat työt erissä
-
käyttävät WP-Cronia tai AJAXia
Nämä kirjastot piilottavat monimutkaisuuden, mutta eivät poista rajoitteita. Ne toimivat vain niin hyvin kuin ympäristö sallii.
Yleinen sudenkuoppa
Moni olettaa, että background processing:
-
toimii kuin oikea job queue
-
kestää tuntikausia
-
ei vaadi valvontaa
WordPressissä tämä ei pidä paikkaansa. Taustatyö on edelleen sidottu HTTP-maailmaan.
Tilan hallinta on tärkeämpää kuin itse työ
Idempotenssi
Hyvä taustaprosessi:
-
voidaan ajaa uudelleen
-
ei tee tuplatyötä
-
kestää keskeytyksiä
Jos työ ei ole idempotentti, se rikkoutuu ennemmin tai myöhemmin.
Missä tila säilytetään
Taustaprosessin tila voidaan säilyttää:
-
tietokannassa
-
object cachessa
-
erillisessä jonossa
wp_options ei ole hyvä paikka suurille tai nopeasti muuttuville tiloille. Silti sitä käytetään usein väärin.
Pitkäkestoiset prosessit ja suorituskyky
Ne kilpailevat käyttäjien kanssa
Taustaprosessit:
-
käyttävät samaa PHP-FPM-poolia
-
kuormittavat tietokantaa
-
vaikuttavat TTFB:hen
Jos niitä ei rajoiteta, ne voivat tehdä sivustosta hitaamman kuin itse liikenne.
Rajoittaminen ja ajoitus
Hyvä ratkaisu:
-
ajaa taustatyöt hiljaisina aikoina
-
rajoittaa rinnakkaisuutta
-
erottaa ne käyttäjäliikenteestä, jos mahdollista
Tämä vaatii tietoista suunnittelua, ei oletuksia.
Autoscale ja background processing
Useampi instanssi, useampi ongelma
Autoscale-ympäristössä:
-
sama taustatyö voi käynnistyä useassa solmussa
-
lukitusmekanismit pettävät
-
tuplatyö lisääntyy
Ilman keskitettyä job runneria pitkäkestoiset prosessit ovat arvaamattomia.
Milloin WordPress ei ole oikea työkalu
On tilanteita, joissa WordPressin taustaprosessit eivät riitä:
-
todella suuret datamassat
-
reaaliaikaiset tapahtumavirrat
-
kriittiset integraatiot
Tällöin parempi ratkaisu on:
-
erillinen worker-palvelu
-
viestijono (queue)
-
WordPressin käyttäminen vain käyttöliittymänä
Tämä ei ole epäonnistuminen, vaan arkkitehtuurinen valinta.
Virheenkäsittely ja näkyvyys
Taustatyö ilman lokia on arvailua
Pitkäkestoiset prosessit:
-
epäonnistuvat ennemmin tai myöhemmin
-
katkeavat ilman varoitusta
-
vaativat jälkikäteen selvittelyä
Ilman kunnollista lokitusta virheiden korjaus on mahdotonta.
Käyttäjäkokemus
Admin-käyttöliittymässä:
-
käyttäjälle pitää kertoa mitä tapahtuu
-
työn tila pitää olla näkyvissä
-
virheistä pitää informoida
“Klikkaa ja odota” ei ole hyväksyttävä malli.
Yleisimmät virheet pitkäkestoisissa prosesseissa
Yleisimpiä virheitä ovat:
-
yhden requestin varaan rakennettu prosessi
-
tilan katoaminen virheessä
-
wp_optionsin väärinkäyttö
-
rinnakkaisuuden hallinnan puute
-
oletus, että prosessi aina pääsee loppuun
Nämä eivät näy heti, mutta näkyvät tuotannossa.
Milloin background processing on onnistunut
Hyvin tehty taustaprosessi:
-
etenee askel kerrallaan
-
kestää keskeytyksiä
-
ei häiritse käyttäjiä
-
voidaan valvoa ja hallita
Usein paras merkki onnistumisesta on se, että prosessi ei vaadi jatkuvaa huomiota.
Lopuksi: WordPress ei ole job queue, mutta se osaa jonottaa
WordPress ei ole rakennettu pitkäkestoisiin prosesseihin, mutta se pystyy käsittelemään ne, kun:
-
työ pilkotaan oikein
-
tila hallitaan huolellisesti
-
odotukset pidetään realistisina
Kun WordPressin rajoitteet hyväksytään ja niitä kunnioitetaan, background processing muuttuu riskistä hallituksi työkaluksi.
Yritä tehdä WordPressistä job runner ja se pettää. Rakenna job runner WordPressin ympärille ja se kestää.
