WordPressin sisäinen roskienkeruu (trash & revisions)

WordPressin sisäinen roskienkeruu kokonaisuutena

WordPressissä on yllättävän kehittynyt, mutta usein huomiotta jäävä sisäinen roskienkeruu. Se koostuu kahdesta päämekanismista: roskakorista (trash) ja revisioista (revisions). Molemmat on rakennettu hyvää käyttökokemusta varten, ei suorituskyky tai tietokannan pitkäaikainen terveys edellä.

Pienellä sivustolla tämä ei tunnu missään. Suuremmassa, pitkään eläneessä WordPressissä nämä mekanismit muuttuvat hiljaiseksi kuormaksi.

Roskakori ei ole vain käyttöliittymäominaisuus

Miten WordPressin roskakori toimii

Kun sisältö poistetaan WordPressissä:

• sitä ei poisteta tietokannasta

• status muuttuu “trash”-tilaan

• rivi jää post-tauluun

Roskakori on viiveellä tapahtuva poisto. Se antaa käyttäjälle turvaverkon, mutta samalla:

• kasvattaa taulujen kokoa

• lisää kyselyiden käonlineltävää datamäärää

• kuormittaa admin-listauksia

WordPress ei koskaan “siivoa heti”.

Roskakorin elinkaari

Oletuksena:

• roskakorissa oleva sisältö poistetaan 30 päivän kuluttua

• poisto tapahtuu WP-Cronin kautta

Jos WP-Cron ei toimi luotettavasti, roskakori:

• ei tyhjene

• kasvaa rajatta

• jää pysyväksi dataksi

Roskakori on siis riippuvainen ajastuksesta, ei ajasta.

Revisiot: hyödyllinen ominaisuus, kallis rakenne

Mikä revisio oikeasti on

Jokainen revisio on:

• täysimittainen post-rivi

• omine meta-arvoineen

• linkitetty alkuperäiseen sisältöön

Revisio ei ole diff. Se on kopio.

Kun sisältöä muokataan usein, revisiot:

• moninkertaistavat datamäärän

• paisuttavat post- ja postmeta-tauluja

• hidastavat kyselyitä ja varmuuskopioita

Revisiot syntyvät herkästi

Revisioita syntyy:

• automaattisesti autosaven yhteydessä

• jokaisesta tallennuksesta

• joskus myös lisäosien toimesta

Sisällöntuottaja ei yleensä tiedä, kuinka monta versiota taustalla syntyy.

Revisiot ja admin-suorituskyky

Adminissa revisiot vaikuttavat erityisesti:

• listanäkymiin

• hakuihin

• COUNT-kyselyihin

Vaikka revisiot eivät näy suoraan käyttöliittymässä, ne ovat mukana tietokantakyselyissä, ellei niitä erikseen rajata pois.

Tämä on yksi syy siihen, miksi admin hidastuu ajan myötä ilman näkyvää syytä.

Roskienkeruu ei ole jatkuvaa

WordPress ei ole garbage-collected järjestelmä

WordPress:

• ei seuraa taulujen kasvua

• ei optimoi dataa automaattisesti

• ei varoita ylikuormituksesta

Roskienkeruu tapahtuu vain:

• tiettyjen tapahtumien yhteydessä

• cron-ajojen kautta

• osittain ja epäsäännöllisesti

Jos cron ei toimi tai sitä on rajoitettu, roskat jäävät.

Revisioiden hallinta arkkitehtuurina

Kaikkia revisioita ei tarvita

Useimmissa tuotantosivustoissa:

• täysi revisiohistoria ei ole tarpeen

• muutama viimeisin riittää

• vanhimmat ovat turhia

Revisiot ovat turvallisuusominaisuus, eivät arkistointijärjestelmä.

Revisiot ja compliance

Joissain ympäristöissä:

• vanhat revisiot sisältävät henkilötietoja

• sisältöä ei saisi säilyttää loputtomiin

• tietojen elinkaari on säädelty

Revisioiden hallinta on tällöin myös juridinen kysymys, ei vain tekninen.

wp_options ei ole syytön sivustakatsoja

Vaikka revisiot ja roskakori liittyvät post-dataan, myös wp_options kärsii:

• siivousasetukset tallentuvat sinne

• lisäosat kirjaavat tilaa ja lippuja

• epäonnistuneet cron-ajot jättävät jälkiä

Huonosti hoidettu roskienkeruu näkyy lopulta myös options-taulussa.

WP-Cron ja roskienkeruun luotettavuus

Cron on heikoin lenkki

Roskienkeruu luottaa WP-Croniin, joka:

• ei ole ajastettu kelloon

• vaatii liikennettä käynnistyäkseen

• voi jäädä kokonaan ajamatta

Tämä tekee siivouksesta epädeterminististä.

System cron vs. WP-Cron

Luotettavassa ympäristössä:

• WP-Cronin sisäinen ajo poistetaan

• järjestelmäcron kutsuu WordPressiä säännöllisesti

• siivous tapahtuu ennustettavasti

Ilman tätä roskienkeruu on toiveajattelua.

Suorituskykyvaikutukset pitkällä aikavälillä

Kertynyt roskadata:

• kasvattaa varmuuskopioiden kokoa

• hidastaa migraatioita

• lisää tietokannan lukituksia

• heikentää adminin vasteaikoja

Nämä eivät näy heti, vaan hiipivät kuukausien tai vuosien aikana.

Milloin roskienkeruu on kunnossa

Hyvin hallittu WordPress:

• ei kerää rajattomasti revisioita

• tyhjentää roskakorin luotettavasti

• ei säilytä turhaa dataa varmuuden vuoksi

Usein paras merkki onnistumisesta on se, että tietokannan koko pysyy vakaana suhteessa sisältömäärään.

Lopuksi: Roskat eivät katoa itsestään

WordPress tarjoaa roskakorin ja revisiot hyvää käyttökokemusta varten. Se ei tarjoa strategiaa niiden hallintaan pitkällä aikavälillä.

Kun roskienkeruu ymmärretään osaksi arkkitehtuuria:

• suorituskyky pysyy tasaisena

• ylläpito helpottuu

• järjestelmä kestää vuosia, ei vain julkaisuhetken

Roskadata ei ole dramaattinen ongelma. Se on hiljainen. Juuri siksi siihen kannattaa puuttua ajoissa.