WooCommercen suorituskyvyn optimoinnin pitäisi vähentää työtä ennen kuin pyyntö päätyy PHP:lle, eikä vain pistää PHP:tä tekemään enemmän töitä. Verkkokauppa, joka ohjaa jokaisen tuoteluettelon pyynnön WordPressin, lisäosien, WooCommerce-istuntojen, Redisin ja MySQL:n kautta, törmää liikenteen kasvaessa ennen pitkää jonoihin, workereiden ylikuormitukseen tai tietokannan lukituskilpailuun.
Suuren liikenteen verkkokaupoissa optimoimme koko pyyntöpolun: Cloudflare → Nginx → PHP-FPM → WordPress → Redis → MySQL. Tavoite on tarkka. Anonyymi liikenne välimuistitetaan turvallisesti, dynaamiset ostopolut säilytetään, jokaisesta pyynnöstä poistetaan tarpeeton koodi ja kalliit workerit suojataan boteilta ja äkillisiltä liikennepiikeiltä.
WooCommerce itse kuvaa tämän eron selvästi: ostoskori-, kassa- ja tilisivujen on pysyttävä dynaamisina, koska ne näyttävät asiakaskohtaisia tietoja. Tuoteluettelo ja muut anonyymit sivut ovat eri asia. Niissä suurin osa toistuvasta liikenteestä voidaan pitää poissa sovelluspinosta, kun välimuistisäännöt suunnitellaan istuntojen ja evästeiden todellisen toiminnan mukaan. WooCommercen välimuistiohjeet tukevat tätä rajausta.
Todellinen pullonkaula on tarpeeton työ
Hidasta verkkokauppaa pidetään usein hostingongelmana. Joskus se sitä onkin. Useammin taustalla on kuitenkin se, että liian moni pyyntö kulkee saman kalliin polun läpi.
Jokainen välimuistin ohittava tuoteluettelon pyyntö voi käynnistää PHP-FPM:n, ladata WordPressin, aktiiviset lisäosat ja WooCommercen tiedot, tehdä kyselyitä MySQL:ään ja tuottaa vastauksen, joka voi olla tuhansille anonyymeille kävijöille täsmälleen sama. PHP-workereiden lisääminen poistamatta tätä työtä yleensä vain siirtää kuormaa eteenpäin: prosessorille, Redisille, MySQL:lle tai ulkoisille rajapinnoille.
Lähestymistapamme on pysäyttää työ aikaisimmalla turvallisella tasolla. Cloudflaren pitäisi tarjoilla välimuistikelpoiset julkiset resurssit ja kelpoiset vastaukset. Nginx FastCGI Cachen pitäisi tarjoilla anonyymi HTML käynnistämättä PHP:tä. PHP-FPM:n pitäisi saada vain pyynnöt, jotka vaativat sovelluslogiikkaa. Redisin pitäisi ottaa vastaan toistuvat objektihaut. MySQL:n pitäisi pysyä vapaana kirjoituksille ja aidosti välimuistin ulkopuolisille luvuille.
| Taso | Päätehtävä | Tyypillinen virhe | Mitä tarkistaa |
|---|---|---|---|
| Cloudflare | Julkisten resurssien ja varmennettujen välimuistikelpoisten vastausten toimitus reunalta | Reunan ohittaminen, koska jokainen vastaus sisältää evästeitä tai rajoittavia välimuistiotsakkeita | Välimuistin tila, otsakkeet, vaihtelu kielen ja valuutan mukaan |
| Nginx | FastCGI-välimuisti, reititys, jonon suojaus, pyyntörajat | Anonyymin HTML:n välittäminen oletuksena PHP:lle | Välimuistin osumaprosentti, upstreamin vasteaika, nopeusrajoitustapahtumat |
| PHP-FPM | Sovelluksen dynaaminen suoritus | Workereiden määrän arvaaminen | Jonotusaika, aktiiviset workerit, prosessori, muisti, p95-viive |
| WordPress ja lisäosat | Vain pyynnön tarvitseman koodin lataaminen | Jokaisen integraation lataaminen jokaisella sivulla | Käynnistysaika, hookit, kyselyt, toiminnalliset regressiot |
| Redis | Objektivälimuisti ja istuntojen tallennus | Toisiinsa liittymättömien kuormien yhdistäminen ilman häätösuunnitelmaa | Muisti, häädöt, osumaprosentti, avainten TTL:t, pysyvyyden kuormitus |
| MySQL | Pysyvä data sekä välttämättömät luvut ja kirjoitukset | Tietokannan käyttäminen ensimmäisenä välimuistitasona | Hitaat kyselyt, lukitukset, yhteyspaine, kirjoitusviive |
Järjestys on tärkeä, koska jokaisella tasolla on erilainen kustannusprofiili. Nginx voi tarjoilla kelvollisen välimuistiosuman käynnistämättä PHP:tä. Nginx dokumentoi FastCGI-välimuistin asetukset, mukaan lukien välimuistin lukituksen ja vanhentuneiden vastausten tarjoilun, jotka voivat vähentää upstreamin kuormaa välimuistimerkinnän päivittyessä.
Näin optimoitte suuren liikenteen WooCommerce-verkkokaupan
Aloittakaa luokittelemalla pyynnöt. Älkää käyttäkö yhtä välimuistikäytäntöä koko verkkokaupalle.
Julkiset tuoteluettelosivut, kategoria-arkistot, tuotesivut, toimituksellinen sisältö ja valitut julkiset API-vastaukset voivat olla ehdokkaita välimuistiin. Ostoskori, kassa, asiakastili, maksujen callbackit, tunnistautuneet pyynnöt ja pyynnöt, joissa ostoskori on aktiivinen, tarvitsevat harkitusti suunnitellun dynaamisen polun. Tämä ero ei ole valinnainen. Välimuistiin tallennettu kassasivu voi muuttua oikeellisuus- ja tietoturvapoikkeamaksi eikä suinkaan suorituskykyparannukseksi.
WooCommercen suorituskykyohjeet suosittelevat lisäksi resurssien ehdollista lataamista, tehokkaita tietokantakyselyitä, lisäosien testaamista ja suorituskykymittauksia. Nämä periaatteet pätevät koko verkkokaupan tasolla eivätkä vain yksittäisten lisäosien tasolla.
Arkkitehtuurin pitäisi tehdä anonyymista tuotesivun katselusta halpaa ja varata sovelluksen kapasiteetti ostoskoriin lisäämiselle, ostoskorin päivityksille, kassalle, maksuille, tilausten tallentamiselle, asiakkaiden toiminnoille ja integraatioille.
Välimuistittakaa anonyymi liikenne rikkomatta personoitua ostamista
Käytämme Nginx FastCGI Cachea, jotta useimmat anonyymit kävijät eivät käynnistä PHP:tä eivätkä WordPressiä lainkaan. Tämä on erityisen arvokasta suurilla tuoteluettelosivuilla, joissa toistuva renderöinti ilman välimuistia voi sitoa workereita vähäisellä liiketoiminta-arvolla.
Välimuistiavainten on heijastettava sitä, miten verkkokaupan versiot eroavat toisistaan. Monikielisissä ja monivaluuttaisissa verkkokaupoissa välimuistiavaimemme sisältää aktiivisen WPML-kielen ja valuuttakontekstin. Ilman tätä vaihtelua kelvollinenkin välimuistiosuma voi näyttää kävijälle väärän kielen tai väärin esitetyt hinnat.
Välimuistin tyhjentämisen jälkeen voimme lämmittää automaattisesti jopa 2 000 sivukartan URL-osoitetta. Lämmittäminen ei korvaa kapasiteettisuunnittelua, mutta se estää sen, että ensimmäiset todelliset kävijät tyhjennyksen jälkeen maksavat suosittujen sivujen uudelleenrakentamisen hinnan. Käymme myös valitut REST-päätepisteet läpi yksitellen. Päätepisteestä tulee reunalla välimuistikelpoinen vasta, kun on varmistettu, ettei sen vastaus riipu asiakkaan evästeistä, ja tarpeeton Set-Cookie- tai Vary: Cookie-käyttäytyminen on poistettu turvallisesti.
Median tallennuksessa voimme pitää kuvat Cloudflare R2:ssa ja toimittaa ne sopivan resurssipolun kautta. Tämä erottaa median tallennuksen WordPress-sovelluksen suorittamisesta. Se ei kuitenkaan poista tarvetta optimoida kuvien mittoja, formaatteja, responsiivista merkintää ja välimuistikäytäntöä.
Käytännön sääntö on yksinkertainen: tallentakaa vastaus välimuistiin vain, kun voidaan osoittaa, että se on sama kaikille käyttäjille, jotka voivat sen saada. WooCommerce määrittelee ostoskorin, kassan ja tilin dynaamisiksi sivuiksi, koska niiden sisältö on asiakaskohtaista.
Laajempaa välimuistitason ulkopuolisten pullonkaulojen tarkastelua varten käyttäkää WordPress-sivustojen auditointipalveluamme ja tunnistakaa sovelluksen, tietokannan, lisäosien ja infrastruktuurin rajoitteet ennen kuin muutatte tuotantosääntöjä.
Vähentäkää WordPressin ja tietokannan työtä Redisillä
Pysyvä Redis-objektivälimuisti vähentää toistuvaa tietokantatyötä, kun WordPress ja WooCommerce pyytävät samoja objekteja yhä uudelleen. Se ei korvaa koko sivun välimuistia. Se on seuraava taso pyynnöille, joiden on joka tapauksessa päädyttävä sovellukseen asti.
Pidämme WordPressin objektivälimuistin ja WooCommercen istunnot erillisissä Redis-instansseissa. Niiden kuormat, avainten elinajat, vikatilanteet ja muistin käyttäytyminen eroavat toisistaan. Objektivälimuistin avaimet ovat kertakäyttöisiä kopioita tietokannan datasta. Istuntoavaimet edustavat asiakkaan aktiivista tilaa, ja niitä on käsiteltävä huolellisemmin.
WooCommercen istuntojen tallennuksen siirrämme taulusta wp_woocommerce_sessions Redisiin. Istuntoavaimilla on TTL:t, ja istuntojen Redis-instanssi voi käyttää volatile-lru-käytäntöä, jolloin häätö kohdistuu avaimiin, joilla on vanhenemisaika, eikä mielivaltaisiin pysyviin avaimiin. Redisin dokumentaation mukaan volatile-lru häätää vähiten äskettäin käytetyt avaimet, joilla on TTL, ja dokumentaatio suosittelee erillisiä instansseja, kun kuormilla on olennaisesti erilaiset pysyvyystarpeet (Redis eviction).
Kun käyttöönoton topologia sen sallii, voimme yhdistää PHP:n Redisiin Unix-socketin kautta TCP:n sijaan. Se on toteutusvalinta, joka pitää mitata, ei yleispätevä sääntö. Socketin oikeudet, konttien rajat, vikasiirron suunnittelu ja havainnoitavuus vaikuttavat kaikki.
Istuntoinstanssi voi käyttää RDB-tilannevedoksia, jolloin istunnot voivat säilyä hallitun uudelleenkäynnistyksen tai saatavilla olevasta tilannevedoksesta palauttamisen yli. RDB on kuitenkin tiettyyn hetkeen sidottua pysyvyyttä eikä lupaus siitä, ettei dataa katoa. Redis huomauttaa, että viimeisimmät kirjoitukset voivat kadota, jos vika sattuu tilannevedosten välillä.
Yhdessä IMADOn kontrolloidussa suorituskykytestissä WooCommerce-istuntojen siirtäminen Redisiin kasvatti suoritettujen iteraatioiden määrää noin 78 %. Varovaisempi suunnitteluhaarukka on 40–60 % lisää läpäisykykyä vastaavassa pullonkaulassa. Tämä on tietyssä ympäristössä havaittu tulos, ei takuu. Lisäosien käyttäytyminen, tuoteluettelon koko, istuntojen määrä, PHP-asetukset, tietokannan suorituskyky ja testikuorman koostumus voivat muuttaa tulosta merkittävästi.
WooCommerce itse vähentää jatkuvasti ytimen kyselytyötä. Esimerkiksi WooCommerce 10.7 toi mukanaan cache primingin, joka kuvatussa skenaariossa vähensi dokumentoidun tilauksia hakevan REST-polun tietokantakyselyt 271:stä 132:een. Tämä vahvistaa saman periaatteen: vähentäkää toistuvaa työtä ennen kuin skaalaatte infrastruktuuria (WooCommerce 10.7).
Säätäkää PHP-FPM ja WordPressin käynnistys pyynnön kontekstin mukaan
Useampi PHP-FPM-worker ei automaattisesti ole parempi. Jokainen worker kuluttaa muistia ja voi lisätä samanaikaista kuormaa MySQL:lle ja ulkoisille palveluille. Mitoitamme workerit suorituskykytesteillä, joissa on realistista liikennettä tuoteluetteloon, ostoskoriin, kassalle, AJAXiin ja integraatioihin.
OPcachen ja WP_CACHE:n pitäisi olla käytössä ja tarkistettuja. Sen jälkeen suurempi hyöty tulee usein siitä, että vähennetään sitä, mitä WordPress lataa jokaisessa pyynnössä.
Käytämme kontekstiin perustuvia lisäosien latausääntöjä Dynamic Plugin Loaderin avulla. Tuoteluettelosivuilla voidaan näin jättää pois maksunvälittäjät, kuljetusyhtiöiden integraatiot, ylläpitotyökalut ja muut lisäosat, joilla ei ole mitään roolia anonyymin tuotelistauksen renderöinnissä. Kassalla maksutoiminnot pysyvät käytettävissä, kun taas ei-välttämättömät SEO-ominaisuudet, tuotesyötteet, toivelistat ja ylläpitotyökalut voidaan jättää pois siellä, missä testit osoittavat, ettei niitä tarvita.
Sääntöjen pitäisi olla erilaiset tuotteille, kategorioille, ostoskorille, kassalle ja AJAXille. WordPressin hallintapaneeli, WP-CLI, cron ja REST API saavat kaikki lisäosat, ellei tiettyä poikkeusta ole testattu. Lisäosien pois jättäminen voi tuoda merkittäviä säästöjä, mutta se on yhteensopivuuden kannalta herkkä optimointi. Testatkaa ennen käyttöönottoa ostoskorin säilyminen, istuntojen jatkuvuus, toimituskulujen laskenta, maksutavat, webhookit, kupongit, asiakastilin toiminnot ja kolmansien osapuolten integraatiot.
Jos verkkokauppaan on vuosien aikana kertynyt lisäosia ja omaa logiikkaa, suorituskykytyö voi vaatia myös laajemman WordPress-ylläpitosuunnitelman kertaluonteisen välimuistikonfiguraation sijaan.
Suojatkaa kalliit workerit liikennepiikkien aikana
Liikennepiikit eivät ole vain kapasiteettiongelma. Ne ovat liikenteen muotoiluongelma.
Säädämme Nginxin ja käyttöjärjestelmän yhteysjonoja niin, että lyhyet piikit voidaan käsitellä hylkäämättä heti oikeutettuja pyyntöjä. Lisäksi rajoitamme pyyntöjen määrää Nginxissä ennen kuin PHP käynnistyy. Näin väärinkäyttävät botit, credential stuffing -yritykset, äänekkäät integraatiot ja liiallinen API-kyselyiden toistelu eivät kuluta workereita, joita oikeat asiakkaat tarvitsevat.
Pyyntörajojen ei pitäisi olla kaikille samat. Kirjautumisella, REST API:lla, AJAXilla, ostoskorilla ja kassalla on erilaiset odotetut liikennemallit ja erilaiset liiketoimintariskit. Kassan suojauksen on oltava riittävän tiukka väärinkäytösten hillitsemiseksi, mutta ei niin aggressiivinen, että se estää oikeita asiakkaita kampanjan aikana.
Sähköpostien muodostaminen on toinen yleinen vältettävissä olevan kassatyön lähde. Kun verkkokaupan ja integraatioiden rakenne sen sallii, siirrämme ei-kriittisten sähköpostien käsittelyn jonoon ja suoritamme sen ajastettuina tehtävinä. Kassapyynnön pitäisi keskittyä tilauksen validointiin, maksun tilan tallentamiseen ja luotettavan vastauksen palauttamiseen.
Siksi suuret kampanjat tarvitsevat myös kenraaliharjoituksen. Testatkaa tuotantoa vastaavaa yhdistelmää: välimuistitetun tuoteluettelon selaamista, hakua, ostoskoriin lisäämisiä, kassayrityksiä, API-pyyntöjä, botteja ja taustatehtäviä. Pelkkään etusivuun kohdistuva kuormitustesti ei ole WooCommercen kapasiteettisuunnitelma.
Mitä mitata ennen jokaista muutosta ja sen jälkeen
Suorituskyvyn optimointi ilman mittaamista muuttuu konfiguraatioperinteeksi. Määrittäkää lähtötaso, muuttakaa yhtä merkityksellistä muuttujaa ja vertailkaa tuloksia samalla liikenneyhdistelmällä.
- Kävijäkokemus: p50-, p95- ja p99-vasteajat tuoteluettelon, tuotteen, ostoskorin ja kassan poluille.
- Välimuistin toiminta: Cloudflaren ja Nginxin välimuistin osumaprosentti, ohitusten syyt, välimuistiavaimen vaihtelu ja lämmityksen valmistuminen.
- PHP-kapasiteetti: aktiiviset ja jonossa olevat PHP-FPM-workerit, prosessien muisti, prosessorin kuormitus ja upstreamin odotusaika.
- Redisin kunto: objektivälimuistin osumaprosentti, muistinkäyttö, häädöt, avainten TTL:t, viive ja pysyvyystoiminnot.
- Tietokannan kuormitus: hitaiden kyselyiden määrä, kyselyviive, lukitusodotukset, yhteydet ja kirjoitussuorituskyky kassan aikana.
- Liiketoiminnan oikeellisuus: ostoskoriin lisäämisen onnistuminen, valmiit kassatapahtumat, maksujen callbackit, tilausten luonti ja virheprosentin muutokset.
Valitkaa näiden mittausten perusteella seuraava pullonkaula. Korkea välimuistin osumaprosentti ja hidas kassa viittaavat työhön dynaamisen sovelluksen, tietokannan, maksujen tai integraatioiden parissa. Matala osumaprosentti julkisilla tuoteluettelosivuilla viittaa välimuistisääntöihin, otsakkeisiin, evästeisiin, vaihteluun tai lämmitykseen.
Verkkokaupoissa, joissa on paljon räätälöityjä toimintoja, WordPress-kehitystiimimme voi puuttua suorituskykyyn koodin ja arkkitehtuurin tasolla sen sijaan, että hoidettaisiin oireita reunalla.
Tarkistuslista tuotantoon viemiseen
- Kirjatkaa lähtötaso tuoteluettelolle, ostoskorille, kassalle, PHP-FPM:lle, Redisille, MySQL:lle ja virheprosenteille.
- Kartoittakaa jokainen reitti välimuistikelpoisuuden ja personointivaatimusten mukaan.
- Toteuttakaa välimuistin vaihtelu kielen, valuutan, perustelluissa tapauksissa laitekohtaisen toiminnan sekä asiakkaan tilan rajojen mukaan.
- Testatkaa FastCGI- ja reunavälimuistin säännöt anonyymin selaamisen, ostoskorin päivitysten, kassan, kirjautumisen, tilitoimintojen ja maksujen callbackien kanssa.
- Siirtäkää objektivälimuisti ja istunnot harkitusti niin, että muistirajat, häätökäytäntö, TTL:t, valvonta ja palautuskäyttäytyminen on määritelty.
- Mitoittakaa PHP-FPM-workereiden määrä realistisella samanaikaisuudella tehdyillä testeillä prosessimäärän maksimoimisen sijaan.
- Ottakaa lisäosien latausäännöt käyttöön konteksti kerrallaan ja pitäkää nopea peruutusreitti valmiina.
- Asettakaa reittikohtaiset pyyntörajat ja testatkaa kampanja- ja bottiskenaariot ennen kuin huippuliikenne alkaa.
- Ottakaa muutokset käyttöön vaiheittain, seuratkaa p95- ja p99-viiveitä sekä liiketoimintatapahtumia ja säilyttäkää edellinen konfiguraatio, kunnes muutos on todettu toimivaksi.
Milloin WooCommercen suorituskyvyn optimointi vaatii insinöörityötä
Välimuistilisäosa voi auttaa yksinkertaista verkkokauppaa. Se ei riitä, kun verkkokaupalla on paljon tuoteluettelon liikennettä, monikielinen hinnoittelu, oma kassalogiikka, ERP- tai CRM-integraatioita, maksunvälittäjiä, ulkoisia rajapintoja, suuri määrä lisäosia, toistuvia kampanjoita tai taustalla tuotantohäiriöitä.
Siinä vaiheessa työ on arkkitehtuuria ja ylläpitoa: välimuistin rajoja, vastausotsakkeita, istuntojen käsittelyä, lisäosien suoritusta, PHP-kapasiteettia, jonojen suojausta, tietokannan käyttäytymistä, käyttöönoton hallintaa ja valvontaa. Oikea toteutus vähentää kuormaa heikentämättä asiakkaan ostopolkua.
Tarvitsetteko verkkokauppa-arkkitehtuurin, joka pysyy nopeana kampanjaliikenteen ja kassahuippujen aikana? Tutustukaa WordPress-nopeusoptimointipalveluumme tai keskustelkaa insinööriemme kanssa.
