Recent Post
WordPress-tietokantaongelmat, jotka hidastavat verkkosivustoa
WordPress-sivusto ei yleensä hidastu siksi, että tietokanta olisi yhtäkkiä “liian suuri”. Useammin ongelma syntyy vähitellen.
Sivustolle kertyy uusia tuotteita, tilauksia, lomakkeiden lähetyksiä, luonnoksia, revisioita ja lisäosien omia tietoja. Samalla käyttöön tulee uusia toimintoja. Aluksi kaikki toimii normaalisti. Sivujen lataus vain alkaa jossain vaiheessa tuntua vähän raskaammalta.
Sitten huomataan, että hallinta tökkii, verkkokaupan tuotteiden avaaminen kestää tai tietty sivu jää lataamaan pitkäksi aikaa.
Tässä vaiheessa tietokanta kannattaa ottaa mukaan tutkimukseen. Kaikki hitaus ei johdu siitä, mutta WordPressissä tietokanta on niin keskeinen osa sivustoa, että sen ongelmat näkyvät helposti muualla asti.
Ensimmäinen merkki ei välttämättä näy tietokannassa
➠ WordPress tekee tietokannan kanssa paljon enemmän työtä kuin pelkkä sivun tekstin hakeminen.
➠ Yhdellä sivulatauksella voidaan hakea esimerkiksi:
- sivun sisältö
- asetuksia
- käyttäjätietoja
- valikkoja
- tuotteita
- tilaustietoja
- lisäosien tallentamia arvoja
- metatietoja
➠ Jos sivulla käytetään useita lisäosia, kyselyiden määrä voi kasvaa nopeasti.
➠ Tämän vuoksi pelkkä tietokannan koko ei vielä kerro, onko siellä ongelmaa. 500 megatavun tietokanta voi toimia hyvin, kun taas paljon pienempi tietokanta voi sisältää kyselyn, joka tekee sivusta hitaan.
➠ Oleellisempi kysymys on: mitä tietokanta joutuu tekemään yhden pyynnön aikana?
Liian monta kyselyä voi olla todellinen pullonkaula
WordPressin hitaus alkaa usein kiinnostaa vasta silloin, kun yksi sivu tekee paljon tietokantakyselyitä.
Yksi kysely ei yleensä ole ongelma. Ongelma syntyy, jos niitä tehdään kymmeniä tai satoja yhden pyynnön aikana, etenkin jos osa kyselyistä on raskaita.
Tilanne voi näyttää esimerkiksi tältä:
Sivu tarvitsee tuotetiedot. Sen jälkeen haetaan tuotteen meta-arvot, kategoriat, varaston tila ja muita lisätietoja. Lisäosa tekee vielä oman kyselynsä samaan tietoon.
Käyttäjälle tämä näkyy vain yhtenä hitaana sivuna.
Kehittäjälle tilanne on toinen. Kun kyselyt käydään läpi, selviääkin, että aikaa ei kulunut itse WordPress-sivun muodostamiseen vaan tietokantaan tehtyihin hakuihin.
Tässä kohtaa lisäosan poistaminen ei välttämättä ole ensimmäinen ratkaisu. Ensin pitäisi selvittää, mikä kysely tekee työn ja miksi sitä tarvitaan niin monta kertaa.
wp_postmeta kasvaa helposti suureksi
Monessa WordPress-projektissa huomio kiinnittyy jossain vaiheessa wp_postmeta-tauluun.
Se sisältää sisältöihin liittyviä metatietoja, ja monet lisäosat käyttävät sitä omien tietojensa tallentamiseen. Verkkokaupassa, sisältörikkaassa sivustossa tai pitkään käytössä olleessa järjestelmässä rivejä voi kertyä paljon.
Suuri rivimäärä ei kuitenkaan automaattisesti tarkoita ongelmaa.
Huolestuttavampaa on se, miten tietoa haetaan.
Jos lisäosa tekee paljon hakuja meta-arvoista ja kyselyt eivät käytä tietokantaa tehokkaasti, sivun vasteaika voi kasvaa huomattavasti. Ongelma korostuu erityisesti silloin, kun dataa on kertynyt vuosien aikana eikä tietokannan rakennetta ole koskaan tarkasteltu suorituskyvyn näkökulmasta.
Siksi wp_postmeta-taulun kohdalla kannattaa katsoa muutakin kuin sen kokoa.
Vanha data jää helposti elämään
➠ WordPress-sivustolle kertyy yllättävän paljon tietoa, jota kukaan ei enää käytä.
➠ Revisiot ovat yksi tuttu esimerkki. Kun sisältöä muokataan jatkuvasti, WordPress voi säilyttää vanhoja versioita. Lisäksi tietokantaan voi jäädä luonnoksia, roskakorissa olevia sisältöjä ja lisäosien vanhoja tietoja.
➠ Myös poistettu lisäosa voi jättää jälkeensä tauluja tai asetuksia.
➠ Tämä ei tarkoita, että kaikki vanha data pitäisi poistaa.
➠ Tietokannan siivoaminen ilman ymmärrystä siitä, mitä tietoja käytetään, voi aiheuttaa enemmän haittaa kuin hyötyä. Ennen poistamista pitää tietää, kuuluuko tieto todella historiaan vai tarvitseeko jokin toiminto sitä edelleen.
➠ Erityisen varovainen kannattaa olla verkkokaupassa. Tilauksiin, asiakkaisiin ja maksuihin liittyvää tietoa ei pidä käsitellä pelkkänä “turhana datana” vain siksi, että sitä on paljon.
Transientit voivat aiheuttaa ongelmia
WordPressin transientteja käytetään väliaikaisen tiedon tallentamiseen. Niistä voi olla paljon hyötyä, mutta niiden hallinta riippuu siitä, miten niitä käyttävä lisäosa on rakennettu.
Jos transientteja syntyy paljon tai niitä jää tietokantaan tarpeettomasti, tietokanta voi kasvaa ilman, että sivuston omistaja huomaa sitä.
Tässä ongelma ei välttämättä ole WordPressissä itsessään. Syynä voi olla lisäosa, joka käyttää transientteja tavalla, joka ei sovi kyseisen sivuston käyttöön.
Siksi ennen siivousta kannattaa selvittää, mikä komponentti tietoa kirjoittaa ja kuinka usein sitä käytetään.
Verkkokaupassa tietokanta joutuu kovemmalle
WooCommerce muuttaa tilannetta huomattavasti.
Tavallisella yrityssivustolla tietokanta käsittelee suhteellisen vähän muuttuvaa liiketoimintadataa. Verkkokaupassa tapahtumia tulee koko ajan lisää.
Tuotteet, asiakkaat, tilaukset ja niihin liittyvät tiedot kasvattavat tietomäärää. Samalla sivustolle voidaan asentaa maksamiseen, toimituksiin, varastoon, markkinointiin ja analytiikkaan liittyviä lisäosia.
Jos verkkokauppa on ollut käytössä useita vuosia, tietokannan suorituskykyä kannattaa tarkastella erikseen. Sama ratkaisu, joka toimi hyvin pienellä tuote- ja tilaustietomäärällä, ei välttämättä toimi yhtä hyvin myöhemmin.
Tässä kohtaa pelkkä palvelimen tehon lisääminen ei aina ratkaise ongelmaa.
Jos tietokantakysely tekee tarpeettoman määrän työtä, tehokkaampikin palvelin joutuu tekemään saman työn.
Lisäosa voi olla hitauden todellinen syy
➠ WordPressissä on helppo ajatella, että “WordPress on hidas”.
➠ Todellisuudessa ongelma voi olla yksittäisessä lisäosassa.
➠ Lisäosa saattaa esimerkiksi:
- tehdä raskaita kyselyitä jokaisella sivulatauksella
- hakea tietoja, joita sivu ei tarvitse
- suorittaa saman haun useita kertoja
- tallentaa paljon dataa tietokantaan
- käyttää tietokantaa välimuistin sijasta
- lisätä omia kyselyitä hallintapaneeliin
➠ Ongelma voi jäädä piiloon kehitysvaiheessa. Pienellä testidatalla kysely toimii nopeasti. Kun tuotannossa on tuhansia tuotteita, käyttäjiä tai tilauksia, sama kysely käyttäytyy aivan eri tavalla.
➠ Tämän vuoksi lisäosan suorituskykyä pitäisi arvioida oikealla datamäärällä, ei vain tyhjässä testiympäristössä.
MySQL:n asetuksia ei kannata lähteä muuttamaan sokkona
Kun WordPress-sivusto hidastuu, houkutus on joskus suuri alkaa säätää tietokantapalvelimen asetuksia.
Se voi olla oikea toimenpide, mutta vasta kun tiedetään, mitä ollaan korjaamassa.
Jos ongelma johtuu huonosta SQL-kyselystä, suurempi muistimäärä ei tee kyselystä automaattisesti hyvää.
Jos taas tietokanta joutuu käsittelemään paljon samanaikaisia pyyntöjä, palvelimen resurssit voivat aidosti olla osa ongelmaa.
Ero selviää mittaamalla.
Tietokannan kuormitusta, hitaita kyselyitä, CPU:n käyttöä, muistia ja levyoperaatioita voidaan tarkastella yhdessä. Sen jälkeen on helpompi päätellä, onko ongelma kyselyssä, tietokannan rakenteessa vai palvelimen resursseissa.
Hidas kysely kannattaa tutkia, ei vain poistaa
Kun ongelmallinen kysely löytyy, seuraava askel ei aina ole sen poistaminen.
Pitää selvittää, mitä kysely tekee.
SQL:n suorittamissuunnitelma voi paljastaa esimerkiksi sen, että tietokanta joutuu käymään läpi huomattavan määrän rivejä löytääkseen tarvitun tiedon.
Tällaisessa tilanteessa indeksi voi auttaa. Joskus taas ongelma on itse kyselyn rakenteessa.
WordPressissä on tärkeää huomioida myös se, että kaikki kyselyt eivät ole sovelluksen omassa koodissa. Niitä voi tulla teemasta, lisäosasta tai niiden yhdistelmästä.
Siksi suorituskykyongelman korjaaminen vaatii usein hieman jäljittämistä.
Välimuisti voi auttaa, mutta se ei korjaa rikkinäistä rakennetta
➠ WordPress-sivustolla välimuisti on usein erittäin hyödyllinen.
➠ Jos sama sivu voidaan tarjota välimuistista, tietokantaa ei tarvitse kuormittaa jokaisella pyynnöllä samalla tavalla.
➠ Mutta välimuisti voi myös peittää ongelman.
➠ Sivusto saattaa näyttää nopealta normaalissa käytössä, koska suurin osa pyynnöistä osuu välimuistiin. Kun välimuisti tyhjennetään tai käyttäjä pyytää tietoa, jota ei ole vielä välimuistissa, taustalla oleva hidas kysely tulee jälleen esiin.
➠ Siksi välimuistia kannattaa pitää suorituskyvyn työkaluna, ei keinona piilottaa tietokantaongelmaa.
Miten ongelmaa kannattaa lähteä selvittämään?
Jos WordPress-sivusto on hidastunut, etenisin käytännössä melko suoraviivaisesti.
Ensin selvittäisin, onko hitaus todella tietokannassa.
Sen jälkeen katsoisin, mitkä sivut ovat hitaita ja tapahtuvatko ongelmat vain tietyissä toiminnoissa. Jos esimerkiksi etusivu toimii nopeasti mutta tuotteen muokkaaminen hallinnassa kestää pitkään, ongelman etsiminen kannattaa rajata siihen toiminnallisuuteen.
Seuraavaksi tarkastelisin tietokantakyselyitä. Erityisen kiinnostavia ovat hitaat kyselyt ja tilanteet, joissa kyselyitä syntyy poikkeuksellisen paljon.
Sen jälkeen tarkistaisin, mikä teema, lisäosa tai oma koodi kyselyt aiheuttaa.
Vasta tämän jälkeen lähtisin muuttamaan tietokannan rakennetta, lisäämään indeksejä tai säätämään palvelimen resursseja.
Tämä järjestys säästää aikaa. Muuten on helppo tehdä monta muutosta yhtä aikaa ja jäädä lopulta epävarmaksi siitä, mikä niistä oikeasti auttoi.
Milloin tietokanta kannattaa siivota?
Siivoukselle on paikka, mutta sitä ei pidä tehdä pelkän tietokannan koon perusteella.
Jos tietokannassa on paljon vanhaa revisiohistoriaa, poistettujen lisäosien jäämiä tai muuta tarpeetonta dataa, siivouksesta voi olla hyötyä.
Ennen sitä kannattaa kuitenkin ottaa toimiva varmuuskopio ja selvittää, mitä ollaan poistamassa.
Tuotantosivustolla erityisesti verkkokaupan tietojen kanssa kannattaa olla varovainen. “Turhan” näköinen taulu voi olla jonkin käytössä olevan lisäosan kannalta olennainen.
Hyvä siivous ei tarkoita sitä, että tietokannasta poistetaan mahdollisimman paljon. Tarkoitus on poistaa sellaista dataa, jota ei enää tarvita ja jonka poistaminen ei riko sivuston toimintaa.
Lopuksi
➠ WordPressin tietokanta ei yleensä muutu ongelmaksi yhden päivän aikana. Useammin sivustolle kertyy vähitellen enemmän sisältöä, käyttäjiä ja toimintoja, kunnes jokin vanha ratkaisu ei enää toimi yhtä hyvin kuin ennen.
➠ Siksi en lähtisi ensimmäisenä suurentamaan palvelinta tai asentamaan uutta välimuistilisäosaa.
➠ Ensin kannattaa selvittää, mitä sivustolla tapahtuu.
➠ Onko kyselyitä liikaa? Onko jokin yksittäinen kysely raskas? Kasvaako jokin taulu tarpeettomasti? Tekevätkö lisäosat samaa työtä monta kertaa? Vai onko ongelma lopulta palvelimen resursseissa?
➠ Kun nämä asiat ovat tiedossa, ratkaisu on yleensä paljon selkeämpi.
➠ WordPress-tietokannan kanssa tärkeintä ei ole tehdä siitä mahdollisimman pientä. Tärkeämpää on, että se tekee vain sen työn, jota sivusto oikeasti tarvitsee.