WordPress-sivuston suorituskykyä käsitellessä keskustelu keskittyy usein välimuistiin, tietokantoihin ja palvelinresursseihin. Yksi vähemmän näkyvä, mutta kriittinen asetus on PHP:n max_execution_time. Se määrittää, kuinka kauan yksittäinen PHP-skripti saa suorittua ennen kuin palvelin keskeyttää sen. Asetus kuulostaa yksinkertaiselta, mutta todellisessa kuormituksessa sen vaikutukset voivat olla yllättävän monimutkaisia.
Moni sivuston ylläpitäjä kohtaa tilanteen, jossa WordPress antaa virheilmoituksen “Maximum execution time exceeded”. Tämä tapahtuu yleensä juuri silloin, kun sivustolla tapahtuu jotain raskasta: varmuuskopiointi, massapäivitys, tuotetuonti tai korkea samanaikainen käyttäjämäärä. Ilmiön ymmärtäminen vaatii hieman kurkistamista siihen, mitä palvelimella oikeasti tapahtuu.
Mitä max_execution_time oikeastaan mittaa
PHP:n max_execution_time on aikaraja, joka koskee yksittäistä skriptin suoritusprosessia. Kun PHP aloittaa skriptin ajamisen, kello alkaa tikittää. Jos suoritusaika ylittää asetetun rajan, skripti keskeytetään väkisin.
Tämä ei kuitenkaan tarkoita, että koko sivun lataus olisi välttämättä niin pitkä. PHP mittaa nimenomaan omaa suoritusosuuttaan, ei kaikkea palvelimen toimintaa. Esimerkiksi tiedonsiirto selaimeen tai ulkoisen API:n viive ei aina kerrytä tätä aikaa samalla tavalla.
Oletusarvot ja hosting-ympäristöt
Useimmissa jaetuissa hosting-ympäristöissä max_execution_time on asetettu arvoon 30 sekuntia. Joissakin ympäristöissä se voi olla 60 sekuntia tai enemmän. Hallinnoiduissa WordPress-palveluissa arvo voi olla korkeampi, koska ympäristö on optimoitu WordPressin tarpeisiin.
Jaetussa hostingissa rajoitus on usein tarkoituksella matala. Se estää yksittäistä sivustoa kuormittamasta palvelinta liikaa. Tämä on kompromissi: turvallisuus ja vakaus vastaan yksittäisen skriptin suoritusvapaus.
Miksi raja ylittyy WordPressissä
WordPress itsessään on suhteellisen kevyt, mutta laajennukset, teemat ja ulkoiset integraatiot voivat tehdä siitä raskaan. Seuraavat tilanteet ovat tyypillisiä max_execution_time-virheiden aiheuttajia:
-
Suuret varmuuskopiot
-
Massatuonti WooCommerceen
-
Kuvatiedostojen optimointi
-
Hakemistojen skannaus
-
Pitkät tietokantakyselyt
-
Ulkoiset API-kutsut, jotka vastaavat hitaasti
Yksittäinen toiminto voi olla teknisesti yksinkertainen, mutta jos se käsittelee tuhansia tiedostoja tai rivejä, suoritusaika kasvaa nopeasti.
Todellinen kuormitus vs. yksittäinen pyyntö
Moni ajattelee, että max_execution_time liittyy vain yksittäisen käyttäjän tekemään pyyntöön. Todellisessa kuormassa tilanne on monimutkaisempi.
Samanaikaiset pyynnöt
Jos sivustolla on esimerkiksi 100 samanaikaista käyttäjää, palvelin ei käsittele yhtä skriptiä, vaan satoja. Jokainen niistä voi käyttää jopa max_execution_time-arvon verran aikaa.
Jos max_execution_time on asetettu hyvin korkeaksi, esimerkiksi 300 sekuntiin, yksittäinen virheellinen skripti voi jäädä roikkumaan pitkäksi aikaa. Tämä sitoo palvelinresursseja ja voi johtaa koko sivuston hidastumiseen.
Prosessien kasaantuminen
Todellisessa kuormassa ongelma ei ole vain yksittäinen hidas skripti, vaan niiden kasaantuminen. Kuvitellaan tilanne:
-
max_execution_time = 120 sekuntia
-
Samanaikaisia käyttäjiä = 50
-
Jokainen pyyntö kestää 90 sekuntia
Palvelin joutuu pitämään käynnissä 50 raskasta PHP-prosessia lähes kahden minuutin ajan. Tämä voi täyttää muistirajat ja CPU-kapasiteetin nopeasti.
WordPressin ajastetut tehtävät ja suoritusajat
WordPress käyttää sisäänrakennettua ajastusjärjestelmää, joka tunnetaan nimellä WP-Cron. Se suorittaa taustatehtäviä, kuten:
-
Julkaisujen ajastukset
-
Sähköpostien lähetys
-
Varmuuskopiot
-
Lisäosien sisäiset tehtävät
WP-Cron ei ole oikea taustaprosessi, vaan se käynnistyy sivulatausten yhteydessä. Tämä tarkoittaa, että yksittäinen käyttäjä voi vahingossa laukaista raskaan tehtävän.
Cron ja max_execution_time
Jos WP-Cron käynnistää raskaan prosessin, kuten varmuuskopion, skripti voi ylittää max_execution_time-arvon. Tällöin:
-
Prosessi keskeytyy
-
Varmuuskopio jää keskeneräiseksi
-
Tietokanta tai tiedostot voivat jäädä epäjohdonmukaiseen tilaan
Tämä on yksi yleisimmistä syistä epävakaisiin WordPress-sivustoihin.
Milloin arvoa kannattaa nostaa
Moni ratkaisee ongelman nostamalla max_execution_time-arvoa. Tämä voi toimia, mutta vain tietyissä tilanteissa.
Perustellut tilanteet
Arvon nostaminen on järkevää esimerkiksi:
-
Suurten varmuuskopioiden yhteydessä
-
Tietokantamigraatioissa
-
Suurissa tuotetuonneissa
-
Kuvien massakäsittelyssä
Näissä tilanteissa tiedetään, että skripti tarvitsee enemmän aikaa, mutta sitä ei ajeta jatkuvasti.
Riskit korkeassa arvossa
Liian korkea max_execution_time voi aiheuttaa:
-
Pitkiä roikkuvia prosesseja
-
Muistin loppumista
-
Palvelimen ylikuormitusta
-
Huonompaa virheiden havaitsemista
Jos skripti jää silmukkaan, se voi jatkaa toimintaansa useita minuutteja ennen keskeytystä.
Suoritusajan optimointi ennen rajan nostamista
Ennen kuin max_execution_time-arvoa nostetaan, kannattaa tarkistaa, miksi skripti kestää niin kauan.
Teeman ja lisäosien tarkistus
Yksi raskas lisäosa voi hidastaa koko sivustoa. Erityisen tunnettuja suoritusajan syöjiä ovat:
-
Monimutkaiset sivunrakentajat
-
Huonosti optimoidut varmuuskopiointilisäosat
-
Reaaliaikaiset tilastotyökalut
Tietokannan optimointi
WordPressin tietokanta voi kasvaa valtavaksi, jos sitä ei siivota. Turhat revisionit, roskakommentit ja vanhat asetukset voivat hidastaa kyselyitä.
Tiedostorakenteen siistiminen
Jos lisäosa skannaa tiedostojärjestelmää, tuhannet vanhat tiedostot voivat hidastaa toimintaa merkittävästi.
Jaetun hostingin erityispiirteet
Jaetussa hostingissa max_execution_time ei ole vain tekninen asetus, vaan myös palveluntarjoajan suojamekanismi.
Rajoitukset ovat tarkoituksellisia
Jaetulla palvelimella:
-
Yksi asiakas ei saa kaataa koko palvelinta
-
Pitkät skriptit katkaistaan automaattisesti
-
Resurssien käyttö pidetään tasaisena
Tämä tarkoittaa, että korkeampi max_execution_time ei välttämättä ole edes mahdollinen.
Ratkaisu: työn jakaminen osiin
Hyvin suunnitellut lisäosat eivät yritä tehdä kaikkea yhdellä skriptillä. Ne:
-
Jakavat työn pieniin osiin
-
Tallentavat välituloksia
-
Jatkavat seuraavalla pyynnöllä
Tämä on paljon vakaampi tapa toimia jaetuissa ympäristöissä.
VPS- ja pilvipalveluympäristöt
VPS:ssä tai pilvipalvelussa max_execution_time-arvoa voi säätää vapaammin. Tämä ei kuitenkaan tarkoita, että arvo pitäisi nostaa äärimmäiseksi.
Tasapaino suoritusajan ja vakauden välillä
Tyypillisiä arvoja ovat:
-
60 sekuntia: kevyt sivusto
-
120 sekuntia: keskiraskas sivusto
-
300 sekuntia: raskaat prosessit
Arvo riippuu:
-
Palvelimen muistista
-
CPU-ytimien määrästä
-
Samanaikaisten käyttäjien määrästä
Käytännön esimerkki todellisesta kuormasta
Kuvitellaan WooCommerce-kauppa, jossa:
-
5 000 tuotetta
-
200 samanaikaista käyttäjää
-
Varmuuskopio käynnissä
-
Kuvien optimointilisäosa aktiivinen
Jos max_execution_time on 300 sekuntia, palvelin voi joutua ajamaan useita raskaita skriptejä yhtä aikaa useiden minuuttien ajan. Tämä voi:
-
Täyttää muistin
-
Hidastaa tietokantaa
-
Aiheuttaa aikakatkaisuja myös kevyille pyynnöille
Jos arvo on 60 sekuntia, raskaat skriptit katkeavat nopeammin, mutta yksittäiset tehtävät voivat epäonnistua.
Todellinen ratkaisu ei ole pelkkä numeron muuttaminen, vaan:
-
Tehtävien ajastaminen
-
Taustaprosessien käyttö
-
Kuormituksen jakaminen
Paras käytäntö: erilliset arvot eri ympäristöihin
Sama max_execution_time ei sovi kaikkiin tilanteisiin.
Kehitysympäristö
Kehityksessä arvo voi olla korkea, esimerkiksi 300 sekuntia. Tällöin pitkät testit eivät keskeydy turhaan.
Tuotantoympäristö
Tuotannossa arvo kannattaa pitää maltillisena, esimerkiksi 60–120 sekuntia. Tämä estää roikkuvat prosessit.
Taustatyöt
Raskaat tehtävät kannattaa ajaa:
-
Erillisessä cron-prosessissa
-
CLI-tilassa
-
Taustajonossa
CLI-skripteissä max_execution_time voidaan usein poistaa kokonaan.
Yhteenveto: numero ei ratkaise kaikkea
max_execution_time on tärkeä turvaraja, mutta se ei ole suorituskykyasetusten kuningas. Liian korkea arvo voi olla yhtä haitallinen kuin liian matala.
Todellisessa kuormassa ratkaisevaa on:
-
Kuinka monta skriptiä ajetaan yhtä aikaa
-
Kuinka paljon muistia ne käyttävät
-
Kuinka hyvin tehtävät on pilkottu osiin
Hyvin rakennettu WordPress-sivusto ei nojaa siihen, että yksittäinen skripti saa viisi minuuttia aikaa. Se nojaa siihen, että työt tehdään tehokkaasti, pienissä erissä ja oikeaan aikaan.
Kun max_execution_time ymmärretään osana kokonaisuutta eikä yksittäisenä taikanumerona, sivuston vakaus ja suorituskyky paranevat usein ilman dramaattisia muutoksia. Se on vähän kuin liikennevalo risteyksessä: sen tehtävä ei ole nopeuttaa autoja, vaan estää kaaos.
