“De winkel laadt traag” is een nuttige opmerking van een klant, maar geen goede diagnose. Een categoriepagina die traag laadt voor iemand die de site voor het eerst bezoekt, is een ander probleem dan een afrekenproces dat vastloopt nadat een betaalmethode is geselecteerd.
Mijn eerste stap is om de klacht om te zetten in een reproduceerbare aanvraag: een URL, de status van de klant, het apparaat, het geschatte tijdstip en de actie. Zonder die gegevens leiden infrastructuurwijzigingen er vaak toe dat de benchmark wordt verbeterd die het gemakkelijkst uit te voeren is.
Zoek eerst de vertraging op voordat je iets afstemt
Ik maak onderscheid tussen drie aspecten: hoe lang het duurt voordat de server met zijn antwoord begint, hoe lang de browser erover doet om de pagina samen te stellen, en hoe lang het duurt voordat een gebruikersactie is voltooid. Een snelle HTML-respons kan nog steeds tot een slechte gebruikerservaring leiden als de browser bezig is met het uitvoeren van overbodige scripts.
Ik vergelijk ook anoniem en geauthenticeerd verkeer. Een goed gevulde cache van openbare pagina’s kan een kostbaar applicatiepad verbergen dat verschijnt telkens wanneer een sessie het antwoord wijzigt. Het herhaaldelijk verversen van één ‘opgewarmde’ pagina geeft geen goed beeld van het klanttraject.
Een bruikbaar onderzoeksrapport bevat onder meer het tijdstip van de verzoek, de cache-status, de grootte van het antwoord, de applicatietrace en de relevante infrastructuurstatistieken uit hetzelfde tijdsbestek. Het is belangrijker om deze waarnemingen met elkaar te vergelijken dan een groot aantal niet-gerelateerde gemiddelden te verzamelen.
Volg het verzoek door de stack heen
Bij een verzoek dat niet in de cache staat, ga ik stap voor stap te werk. Wacht de webserver op een beschikbare PHP-worker? Is PHP bezig met databaseverzoeken? Voert een module een synchroon verzoek uit naar een externe dienst? Concurreert het verzoek met cataloguswerkzaamheden?
| Opmerking | Volgende vraag |
|---|---|
| De vertraging neemt toe bij invoer | Zijn indexerings- of database-schrijfbewerkingen in conflict met verzoeken van klanten? |
| Alleen de pagina’s waarvoor je moet inloggen, laden traag | Welke niet-gecachete blokken of klantspecifieke bewerkingen spelen de grootste rol? |
| Het afrekenen wordt af en toe onderbroken | Is er een afhankelijkheid met betrekking tot verzending, belasting of betaling die wacht zonder een zinvolle time-out? |
| De server reageert snel, maar de interactie verloopt traag | Wat houdt de hoofdthread van de browser bezig? |
Ik vermijd het om het aantal workers te verhogen totdat ik inzicht heb in het geheugengebruik en de capaciteit verderop in het proces. Meer gelijktijdige PHP-taken kunnen ervoor zorgen dat een wachtrij op applicatieniveau uitgroeit tot een grotere wachtrij bij de database. Wijzigingen in de gelijktijdigheid moeten worden onderbouwd met meetgegevens.
Controleer het werk dat door uitbreidingen is geïntroduceerd
Dankzij het uitbreidingsmodel van Magento kunnen verschillende modules, die afzonderlijk gezien redelijk zijn, samen extra belasting op één verzoek veroorzaken. Een productvermelding kan bijvoorbeeld leiden tot het extra laden van collecties, controles op afstand of herhaaldelijk opvragen van configuratiegegevens. De totale belasting is wat de klant ervaart.
In een gecontroleerde omgeving vergelijk ik de loggegevens terwijl het vermoedelijke gedrag is uitgeschakeld. Het doel is om de bewerking te identificeren die verantwoordelijk is voor de vertraging, en niet om elke module van een derde partij als een probleem aan te merken. Als een functie noodzakelijk is, kan het de juiste oplossing zijn om de verwerking ervan buiten het kritieke verzoekspad te plaatsen.
Caching helpt alleen als de cache-sleutel en het ongeldigverklaringsgedrag overeenkomen met de gegevens. Klantspecifieke informatie mag niet zomaar tot gedeelde inhoud worden gemaakt, louter om een tijdschema te verbeteren. De documentatie van Adobe over caching is nuttig om inzicht te krijgen in de cachelagen van het platform voordat je deze wijzigt.
Controleer aan de hand van een traject, inclusief de trage gevallen
Mijn testtraject omvat een categoriepagina, een product met varianten, het toevoegen aan het winkelmandje, het doorlopen van het afrekenproces en de betreffende integratiegrenze. Ik vergelijk de verdeling van de verzoeken, inclusief tragere reactietijden, in plaats van één succesvol voorbeeld te laten zien.
De wijziging moet ook operationeel worden gecontroleerd. Is de belasting van de database toegenomen? Is er een achterstand ontstaan bij geplande taken? Is het foutenpercentage gestegen terwijl de pagina sneller is geworden? Een lokale verbetering kan het probleem naar een minder zichtbare plek verplaatsen.
Ik beschouw het onderzoek als afgerond wanneer ik de oorspronkelijke vertraging kan verklaren, kan aantonen dat de betreffende reis onder vergelijkbare omstandigheden is verbeterd, en kan beschrijven hoe de wijziging zich tijdens drukke periodes gedraagt. Die uitleg is nuttiger dan nog een reeks serverupgrades.
Bijgewerkt op 25 september 2026.