WordPress ja palvelintason throttling

Kun WordPress-sivusto hidastuu tai kaatuu kuormapiikin aikana, katse kääntyy usein koodiin, lisäosiin tai välimuistiin. Todellinen pelastaja – tai hiljainen sabotoija – löytyy kuitenkin usein alempaa: palvelintason throttlingista. Se ei ole virhe, vaan tarkoituksellinen rajoitus. Ongelma syntyy, kun sitä ei ymmärretä tai se on ristiriidassa WordPressin toimintamallin kanssa.

Throttling ei tee sivustosta nopeaa. Se tekee siitä hengissä pysyvän.

Mitä throttling tarkoittaa käytännössä

Palvelintason throttling tarkoittaa:

• resurssien käytön rajoittamista

• pyyntöjen hidastamista tai katkaisemista

• priorisointia kuormituksen aikana

Rajoituksia voidaan asettaa:

• CPU:lle

• muistille

• prosessimäärälle

• verkkopyynnöille

• PHP-FPM workerien määrälle

• HTTP-pyyntöjen nopeudelle

WordPress ei tiedä throttlingista mitään. Se vain reagoi seurauksiin.

Miksi WordPress on herkkä throttlingille

WordPress:

• on dynaaminen

• käyttää PHP:tä joka pyynnöllä

• luottaa usein tietokantaan

• käynnistää koko ympäristön jokaisessa requestissa

Jos:

• yksi käyttäjä tekee monta pyyntöä

• botti indeksoi aggressiivisesti

• REST- tai AJAX-endpointia kutsutaan tiheästi

throttling aktivoituu nopeasti.

CPU- ja prosessirajat

Jaetuissa ja konttipohjaisissa ympäristöissä:

• CPU-aika on rajattu

• prosessit voivat jonoutua

• PHP-FPM jää odottamaan

WordPress-oireet:

• hitaat sivulataukset

• wp-admin “jumittaa”

• satunnaiset timeoutit

Tämä ei ole PHP-bugi, vaan resurssipolitiikka.

PHP-FPM ja throttling

PHP-FPM on yksi kriittisimmistä kerroksista:

• Kopioi

  pm.max_children

  rajoittaa rinnakkaisuutta

• liian matala arvo → jonoutuminen

• liian korkea arvo → muistin loppuminen

Kun throttling iskee:

• requestit jäävät jonoon

• käyttäjä kokee sivuston kaatuneeksi

• mutta palvelin on “teknisesti kunnossa”

WordPress ei skaalaudu ilman suunniteltua FPM-konfiguraatiota.

HTTP-tason throttling

Web-palvelin tai reverse proxy voi:

• rajoittaa pyyntöjen määrää IP:tä kohti

• hidastaa liian tiheitä kutsuja

• suojata brute force -hyökkäyksiltä

Hyvä:

• suojaa wp-loginia

• estää botteja

Huono:

• rikkoo AJAX-toiminnot

• katkaisee REST API -integraatiot

• aiheuttaa 429-virheitä

Throttling ilman kontekstia on sokea.

CDN ja edge-throttling

CDN:t:

• rajoittavat pyyntöjä globaalisti

• estävät hyökkäyksiä ennen palvelinta

• suojaavat alkuperää

WordPressissä:

• staattinen sisältö hyötyy

• dynaaminen liikenne voi kärsiä

• kirjautuneet käyttäjät ohittavat CDN:n

Edge-throttling on tehokasta vain, jos cache-strategia on kunnossa.

Throttling ja REST API

REST API on erityisen altis:

• koneet kutsuvat sitä

• kutsut voivat olla tiheitä

• virheet eivät näy käyttäjälle heti

Ilman rate limiting -strategiaa:

• yksi huono integraatio voi tukahduttaa palvelimen

• throttling iskee kaikkiin

REST API vaatii eksplisiittisen suojauksen.

wp-admin ja throttling

Admin-puoli:

• käyttää AJAXia

• tekee useita pyyntöjä yhdellä sivulla

• reagoi huonosti viiveisiin

Kun throttling osuu adminiin:

• editori hidastuu

• tallennukset epäonnistuvat

• käyttäjät menettävät luottamuksen

Admin ei ole vähemmän tärkeä kuin frontend.

Throttling vs. cache

Cache:

• vähentää pyyntöjen määrää

• pienentää kuormaa

• auttaa throttlingin välttämisessä

Mutta:

• cache ei auta kirjautuneita käyttäjiä

• cache ei suojaa write-operaatioita

• cache ei korjaa huonoa endpoint-suunnittelua

Throttling on viimeinen turvaverkko, ei optimointityökalu.

Milloin throttling kannattaa ottaa käyttöön

Throttling on perusteltua, kun:

• liikenne on ennakoimatonta

• botti- ja hyökkäysliikenne on todellista

• ympäristö on jaettu

• resurssit ovat rajalliset

Se ei ole ratkaisu, jos:

• sivusto on jatkuvasti hidas

• käyttäjät kokevat virheitä normaalikäytössä

Tyypilliset virheet

Yleisiä kompastuskiviä:

• throttling ilman lokitusta

• sama raja kaikille endpointille

• ei eroa GET- ja POST-pyynnöille

• admin ja frontend samalla säännöllä

• ei retry-logiikkaa

Hyvä throttling on hienovarainen.

Miten WordPress-kehittäjä voi vaikuttaa

Vaikka throttling on palvelintasolla, kehittäjä voi:

• vähentää pyyntöjen määrää

• yhdistää API-kutsuja

• cachetaa tuloksia

• estää turhat AJAX-pyynnöt

• rajata REST-endpointit

Hyvä koodi vähentää tarvetta rajoituksille.

Throttling ja autoscale

Autoscale ei poista throttlingia:

• skaalaus vie aikaa

• äkilliset piikit osuvat silti

• jokaisella instanssilla on rajat

Throttling suojaa skaalautumista.

Lopuksi: throttling on osa arkkitehtuuria

Palvelintason throttling ei ole vihollinen. Se on osa modernia web-arkkitehtuuria, jossa:

• kaikki liikenne ei ole luotettavaa

• resurssit eivät ole rajattomat

• WordPress ei ole yksin maailmassa

Kun throttling suunnitellaan yhdessä WordPressin toimintamallin kanssa, lopputulos ei ole hidas sivusto. Se on vakaa sivusto.