WordPressin tietokantakyselyiden optimointi WP

Tiivistelmä

WordPress hakee artikkeleita, sivuja ja muita sisältöjä tietokannasta. Tavallisella sivustolla näiden hakujen toteutusta ei tarvitse miettiä päivittäin. Sisältömäärän kasvaessa tai omia listauksia rakennettaessa…

WP_Query on WordPressin luokka sisältöjen hakemiseen. Sillä voidaan rajata tuloksia esimerkiksi sisältötyypin, kategorian, julkaisupäivän tai lisäkentän perusteella. Joustavuus tuo mukanaan vastuun: toimiva kysely voi tehdä huomattavasti enemmän työtä kuin sivun näyttäminen edellyttää.

Optimoinnin tavoitteena on hakea tarvittavat tiedot mahdollisimman tarkoituksenmukaisesti. Samalla pitää säilyttää oikeat hakutulokset, sivutus ja käyttöoikeuksien mukainen näkyvyys.

Selvitä ensin, mikä kysely on hidas

Älä aloita lisäämällä suorituskykyasetuksia jokaiseen kyselyyn. Mittaa ensin, mihin sivun muodostamiseen käytetty aika kuluu.

Tutki testiympäristössä tietokantakyselyiden kestoa, toistuvuutta ja niitä käynnistäviä toimintoja. Palvelimen suorituskykyloki tai kyselyitä näyttävä diagnostiikkatyökalu auttaa paikantamaan ongelman.

Kiinnitä huomiota esimerkiksi seuraaviin havaintoihin:

Sama sisältö haetaan useita kertoja yhden pyynnön aikana.
Yksi kysely kestää huomattavasti muita pidempään.
Jokainen listauksen artikkeli käynnistää uuden lisähaun.
Kysely palauttaa paljon enemmän sisältöä kuin sivulla näytetään.
Haku hidastuu selvästi sisältömäärän kasvaessa.

Kyselyiden lukumäärä ei yksin ratkaise suorituskykyä. Usea nopea haku voi olla kevyempi kuin yksi monimutkainen kysely. Tarkastele kokonaiskestoa ja sivun todellista käyttötarkoitusta.

Rajaa haettavien sisältöjen määrä

Ensimmäinen käytännön parannus on määritellä, kuinka monta tulosta tarvitaan. Jos sivulla näytetään kuusi artikkelia, kyselyn ei tarvitse palauttaa koko arkistoa.

Seuraava esimerkki hakee kuusi uusinta julkaistua artikkelia:

$uutiset = new WP_Query(
    array(
        'post_type'           => 'post',
        'post_status'         => 'publish',
        'posts_per_page'      => 6,
        'orderby'             => 'date',
        'order'               => 'DESC',
        'ignore_sticky_posts' => true,
        'no_found_rows'       => true,
    )
);

ignore_sticky_posts estää kiinnitettyjen artikkelien erityiskäsittelyn; se ei sulje niitä kokonaan tuloksista. Esimerkki sopii kiinteään nostolistaukseen.

Vältä verkkosivun tavallisissa listauksissa asetusta posts_per_page => -1, joka poistaa tulosmäärän rajoituksen. Suurissa aineistoissa käsittele sisältöä rajattuina erinä. Tarkat rajausvaihtoehdot löytyvät WP_Query-luokan parametrikuvauksesta.

Ohita kokonaismäärän laskenta vain tarvittaessa

Edellisen esimerkin no_found_rows on hyödyllinen silloin, kun tarvitset vain rajatun tulosjoukon. Se ohittaa sivutusta varten tehtävän kaikkien osumien määrän selvittämisen.

Sivupalkin uusimpien artikkelien listan ei yleensä tarvitse tietää, löytyisikö hakuehdoilla kuusi vai kuusituhatta artikkelia. Numeroitu arkistosivutus puolestaan tarvitsee tavallisesti kokonaismäärän.

Älä siis aseta no_found_rows-arvoa todeksi kyselyyn, jonka found_posts– tai max_num_pages-tietoja käytät. Muuten listaus voi näyttää oikealta ensimmäisellä sivulla, mutta sivumäärä jää virheelliseksi. WordPress VIP:n kyselyoptimoinnin ohje

Ratkaise ensin käyttöliittymän tarve. Pelkkä seuraavien tulosten lataaminen voidaan toteuttaa ilman täsmällistä kokonaismäärää, mutta se vaatii siihen suunnitellun toteutuksen.

Hae pelkät tunnisteet, jos ne riittävät

Kaikki käsittely ei tarvitse kokonaisia artikkeliolioita. Jos tehtävänä on välittää sisältöjen tunnisteet seuraavaan käsittelyvaiheeseen, voit pyytää ID-arvot:

$tunnistehaku = new WP_Query(
    array(
        'post_type'      => 'post',
        'post_status'    => 'publish',
        'posts_per_page' => 100,
        'fields'        => 'ids',
        'no_found_rows' => true,
    )
);

$artikkeli_idt = $tunnistehaku->posts;

Tämä sopii rajattuun taustakäsittelyn erään. Se ei ole automaattisesti paras vaihtoehto artikkelikorttien näyttämiseen.

Jos haet heti jokaiselle tunnisteelle erikseen otsikon, otteen, kuvan ja lisäkentät, saatat tehdä tarpeettomia lisähakuja. Valitse palautusmuoto koko käsittelyketjun perusteella. WP_Query-luokan palautuskentät

Muokkaa pääkyselyä ylimääräisen haun sijaan

WordPress muodostaa esimerkiksi kategoria-arkiston pääkyselyn jo valmiiksi. Jos haluat muuttaa vain näytettävien artikkelien määrää, uutta kyselyä ei yleensä tarvita.

Pääkyselyä voidaan muokata pre_get_posts-koukulla:

function oma_sivusto_kategoria_maara( $query ) {
    if ( is_admin() || ! $query->is_main_query() ) {
        return;
    }

    if ( $query->is_category() ) {
        $query->set( 'posts_per_page', 12 );
    }
}

add_action(
    'pre_get_posts',
    'oma_sivusto_kategoria_maara'
);

Esimerkki rajaa muutoksen julkisen puolen kategoria-arkistojen pääkyselyyn. Se kuuluu esimerkiksi sivuston omaan lisäosaan tai lapsiteeman toimintoihin.

Rajaukset ovat tärkeitä. Ilman niitä sama muutos voisi vaikuttaa hallintapaneeliin tai sivun muihin listauksiin. Käytä koukussa käsiteltävän kyselyolion tarkistusmenetelmiä. pre_get_posts-koukun dokumentaatio

Vältä kyselyiden tekemistä silmukan sisällä

Yleinen suorituskykyongelma syntyy, kun jokainen listauksen rivi käynnistää uuden haun. Kahdenkymmenen artikkelin näkymä voi silloin tehdä päähaun lisäksi kaksikymmentä erillistä kyselyä.

Näin voi tapahtua esimerkiksi silloin, kun jokaisen artikkelin yhteydessä haetaan saman kirjoittajan muita julkaisuja.

Selvitä, voitko hakea tarvittavat tiedot yhdessä erässä ja järjestää ne PHP:ssä sopivaan rakenteeseen. Jos samaa tietoa tarvitaan monta kertaa, säilytä jo saatu tulos muuttujassa.

Älä kuitenkaan ratkaise ongelmaa hakemalla koko tietokantaa kerralla. Yhteishaunkin tulee olla rajattu kyseisellä sivulla tarvittaviin sisältöihin.

Mittauksessa kannattaa vertailla sekä tietokantaan käytettyä aikaa että muistinkulutusta. Yhden osa-alueen parantaminen voi kasvattaa toisen kuormitusta.

Käsittele metatietohakuja harkiten

meta_query mahdollistaa sisältöjen rajaamisen lisäkenttien perusteella. Laajoissa aineistoissa useat metatietoehdot, OR-yhdistelmät ja arvojen muunnokset voivat tehdä kyselystä raskaan.

Mieti tietomallia ennen ehtojen lisäämistä. Jos kenttä kuvaa toistuvaa luokittelua, kuten tapahtuman tyyppiä tai palvelun aihealuetta, taksonomia voi sopia tarkoitukseen paremmin.

Päivämäärät ja numeeriset arvot tarvitsevat puolestaan johdonmukaisen tallennusmuodon. Sekalaiset tekstiarvot vaikeuttavat tehokasta vertailua ja järjestämistä.

Tarkista myös tietokannan indeksit ja kyselyn suoritussuunnitelma ennen suuria rakennemuutoksia. Erityisesti paljon suodatettavalle tiedolle voidaan tarvita tarkoitukseen suunniteltu tallennusratkaisu. Yleinen metatietotaulu ei ole paras vastaus jokaiseen käyttötapaukseen. WordPress VIP:n tietokantakyselyiden optimointiohje

Suunnittele järjestäminen ja sivutus aineiston mukaan

Satunnainen järjestys voi olla kallis tapa muodostaa pieni nostolista suuresta aineistosta. Jos vaihtuva sisältö riittää, harkitse etukäteen koottua valikoimaa, jota päivitetään sopivin väliajoin.

Myös syvälle ulottuva sivutus kannattaa mitata. Vaikka käyttäjälle palautetaan vain muutama tulos, tietokanta voi joutua käsittelemään paljon ohitettavia rivejä.

Tavalliseen blogiarkistoon normaali sivutus sopii usein hyvin. Erittäin suureen syötteeseen voidaan suunnitella viimeksi näytettyyn päivämäärään ja tunnisteeseen perustuva eteneminen.

Tällaisessa toteutuksessa järjestyksen pitää olla yksiselitteinen. Samalla julkaisuajalla olevat artikkelit tarvitsevat toissijaisen järjestyskriteerin, jotta sisältöjä ei jää välistä tai näy kahdesti.

Älä vaihda sivutusmallia pelkän oletetun nopeushyödyn vuoksi. Varmista ensin, että juuri sivutus aiheuttaa mitattavan ongelman.

Säilytä hyödyllinen välimuisti

WP_Query hyödyntää WordPressin välimuistimekanismeja. Pysyvä objektivälimuisti voi mahdollistaa tietojen hyödyntämisen myös eri pyyntöjen välillä. Asetus cache_results => false ei siksi ole yleinen nopeutuskeino. WordPressin kyselyvälimuistin toimintaperiaate

Myös metatietojen ja taksonomiatietojen esilatauksen poistaminen pitää perustella käyttötarpeella. Jos tiedot luetaan myöhemmin jokaiselle artikkelille, niiden lataaminen yhdessä voi olla tehokkaampaa.

Erikseen laskettuja, kalliita tuloksia voidaan säilyttää transientissa. Suunnittele silloin välimuistiavaimeen kaikki tulokseen vaikuttavat rajaukset sekä tapa vanhentaa tulos sisällön muuttuessa.

Transientti voi poistua ennen määritettyä vanhenemisaikaa. Toteutuksen pitää pystyä muodostamaan puuttuva arvo uudelleen. Käyttäjäkohtaisia tuloksia ei saa jakaa muille yhteisen välimuistiavaimen kautta. WordPressin Transients API

Varmista tulokset ennen muutoksen julkaisemista

Tee optimointi ensin testiympäristössä ja muuta yhtä asiaa kerrallaan. Vertaa tuloksia sekä kylmällä että valmiiksi käytetyllä välimuistilla.

Tarkista nopeuden lisäksi toiminnallinen oikeellisuus:

Näkyvätkö samat julkaisut kuin ennen?
Säilyykö haluttu järjestys?
Toimivatko seuraavat sivut?
Käsitelläänkö tyhjä tulosjoukko oikein?
Pysyvätkö luonnokset ja yksityiset sisällöt poissa julkisesta listasta?

Jos oma silmukka käyttää the_post()-menetelmää, palauta sen jälkeen artikkelikonteksti wp_reset_postdata()-kutsulla.

Kirjaa lopuksi alkuperäinen ongelma, tehty muutos ja mitattu vaikutus. Hyvä optimointi vähentää tarpeetonta työtä ja säilyttää samalla sivuston käyttäytymisen ymmärrettävänä.

Liittyvät kategoriat

Artikkeleita 2 032 artikkelia IT 1 958 artikkelia Kotisivut 1 207 artikkelia Nettisivut 1 207 artikkelia Verkkokehitys 1 273 artikkelia Verkkosivut 1 406 artikkelia Verkkotyökalu 1 186 artikkelia WordPress 1 226 artikkelia