De melding “Fatal error: Maximum execution time of 30 seconds exceeded” komt op enig moment op vrijwel elke WordPress-site voorbij. De max execution time is een instelling van uw server die zegt hoelang één handeling maximaal mag duren. Wordt die tijd overschreden, dan wordt het proces afgebroken, en dan ziet u die regel of een half geladen pagina.
Het advies dat u overal leest, is om de limiet te verhogen. Dat werkt vaak, en het is meestal niet het goede antwoord. Deze melding is namelijk zelden het probleem; hij is de manier waarop uw server u vertelt dat er iets te zwaar is geworden.
Waar de max execution time in WordPress voor bedoeld is
Uw server kan een beperkt aantal handelingen tegelijk uitvoeren. Zou er geen tijdslimiet zijn, dan kan één vastgelopen proces eindeloos blijven draaien en langzaam alle capaciteit opeten. Na een uur staat de hele server vast, ook voor uw andere pagina’s en voor de andere klanten op hetzelfde pakket.
De standaardwaarde is dertig seconden op de meeste gedeelde hosting, soms zestig. Voor een normale paginaweergave is dat belachelijk ruim: die hoort in een tiende van een seconde klaar te zijn. Loopt u tegen dertig seconden aan, dan gebeurt er dus iets uitzonderlijks.
Overigens geldt de limiet niet voor werk op de opdrachtregel. Dat is precies de reden dat beheerders zware klussen daar uitvoeren; meer daarover staat bij de geplande taken die WordPress op de achtergrond uitvoert.
Wanneer de melding onschuldig is
Er zijn situaties waarin dertig seconden gewoon te weinig is en er niets mis is.
- Een grote import. Duizend producten uit een bestand inlezen duurt nu eenmaal langer dan een halve minuut.
- Een volledige back-up van een site van enkele gigabytes.
- Het opnieuw aanmaken van alle afbeeldingsformaten na een themawissel.
- Een eenmalige zoek-en-vervangactie in de database na een verhuizing.
In deze gevallen is de limiet tijdelijk verhogen naar driehonderd seconden een verstandige keuze, mits u hem daarna weer terugzet. Een goede importplugin doet dit trouwens zelf al door in blokken te werken en tussendoor opnieuw te starten; loopt uw plugin daarop stuk, dan is dat een aanwijzing dat het geen goede plugin is.
Wanneer de melding wél een signaal is
Zorgelijker wordt het als de melding verschijnt bij gewone handelingen. Dan is er iets structureel mis.
Bij het openen van een normale pagina. Iets in die pagina wacht op iets anders. Meestal is dat een externe koppeling die niet antwoordt: een voorraadsysteem, een boekhoudpakket, een sociale tijdlijn. Uw site blijft dan wachten tot de tijd om is en breekt dan af.
Bij het opslaan van een pagina in een paginabouwer. Vaak een teken dat de pagina te veel losse onderdelen bevat, of dat er een zwaar element in zit dat bij elke opslag opnieuw wordt berekend.
In een overzicht in het beheerscherm. Een lijst met bestellingen of gebruikers die alles tegelijk probeert op te halen. Dit gaat vaak samen met een trage database.
Willekeurig, meerdere keren per dag. Dit wijst op een overvolle server: uw handeling krijgt niet genoeg rekentijd omdat anderen op hetzelfde pakket het druk hebben.
Hoe u de oorzaak vindt
- Noteer wanneer het gebeurt. Bij welke handeling, op welke pagina, hoe vaak. Dit is het halve werk en het kost u niets.
- Kijk in het foutenlogboek. Daar staat vaak niet alleen de melding maar ook het bestand en de regel waar het proces afbrak. Dat bestand zit meestal in de map van een specifieke plugin, en daarmee heeft u uw verdachte.
- Zet plugins in een testomgeving uit en kijk of het verdwijnt. Werk daarna terug in kleine stappen.
- Controleer of er externe koppelingen actief zijn. Elke plugin die bij het laden gegevens ophaalt bij een andere partij, is een kandidaat.
- Kijk of het samenhangt met de geheugenlimiet. Deze twee treden vaak samen op; wat u daaraan doet staat bij het aanpassen van de geheugenlimiet van WordPress.
Verhogen: wanneer wel en wanneer niet
Verhogen is verdedigbaar bij een eenmalige zware klus, bij een import die nu eenmaal twee minuten kost, of als tijdelijke maatregel terwijl u de echte oorzaak zoekt.
Verhogen is een slecht idee als de melding op gewone pagina’s verschijnt, als u hem al twee keer eerder heeft verhoogd, of als u niet weet wat er die tijd opsoupeert. In dat laatste geval geeft u een vastgelopen proces simpelweg meer ruimte om vast te lopen.
Bedenk ook wat een bezoeker ervaart. Een pagina die na het verhogen in tweeënveertig seconden laadt in plaats van af te breken, is voor uw bezoeker geen verbetering: hij is allang weg. De melding is dan verdwenen en het probleem niet.
Wilt u het toch aanpassen, dan doet u dat in uw hostingpaneel bij de PHP-instellingen, of u vraagt het aan uw hostingpartij. Zet het op driehonderd seconden voor een eenmalige klus en daarna terug op zestig.
De achterliggende vraag
Bij vrijwel elke site waar deze melding structureel terugkomt, is het antwoord uiteindelijk hetzelfde: er is iets gegroeid zonder dat iemand meekeek. Een webshop die van vierhonderd naar zesduizend producten ging op hetzelfde pakket. Een plugin die er in de loop der jaren bij kwam en bij elk bezoek gegevens opvraagt. Een database die nooit is opgeruimd.
Dat is geen ramp en het is ook niemands schuld. Het is wel het moment om te kijken of uw hosting nog past bij wat uw site doet. Die vraag beantwoordt u met meten: hoeveel van die dertig seconden gaat er naar de database, hoeveel naar externe koppelingen en hoeveel naar het thema.
Dat meetwerk is het eerste dat wij doen bij het uitzoeken van een terugkerende fatale fout, nog voordat er een instelling wordt aangeraakt. In ongeveer de helft van de gevallen blijkt de oorzaak dan één plugin te zijn die op iets zit te wachten. Die uitzetten kost vijf minuten. De limiet ophogen kost ook vijf minuten, maar dan bent u over twee maanden terug bij hetzelfde scherm.
