WordPress ja pitkäkestoiset prosessit (background processing)

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ää.