Het wil wel eens voorkomen dat je site langzaam reageert of heel lang doet om een pagina in te laden. Dit soort problemen zijn natuurlijk funest als hierdoor bezoekers snel afhaken van je website. In dit artikel geven wij praktische tips over hoe je dit soort problemen kunt oplossen.

New Relic!

We ondersteunen New Relic bij de Magento Grow, Professional en Pro pakketten,  Dedicated Magento Clusters,  Optimize pakketten & MCU’s. New Relic is de ultieme tool waarmee je een website kunt debuggen. Het geeft heel gedetailleerd inzicht in performance en bottlenecks. In een mum van tijd zie je waar het fout gaat. Lees meer over New Relic in het artikel New Relic.

Scan je website met GTmetrix

Geen New Relic account? Dan kun je ook tools als GTmetrix gebruiken om vast te stellen waar het probleem globaal zit. Door middel van de timeline functie kun je kijken hoelang het duurde om een DNS lookup te doen, de pagina op te vragen en om de pagina te renderen.
Hieronder in afbeelding 1 staat de analyse van Byte.nl. Byte.nl is aan de frontend al tamelijk ver geoptimaliseerd. We zien dat er 462ms gewacht moet worden. Dit is doorgaans de tijd die scripts nodig hebben om uit te voeren. Als dit te hoog is zul je dus in de code moeten gaan duiken om te kijken wat er traag is.

Analyse van GTmetrix

afb. 1 GTmetrix
Tools als GTMetrix geven echter geen uitgebreidere informatie over waar het probleem in de code zit. Ze kunnen enkel indiceren of het in de backend (PHP, MySQL, Server etc.) of in de frontend (HTML, CSS, Javascript etc.) zit en kunnen verder tips geven over frontend optimalisatie. Zie ook: http://developer.yahoo.com/yslow/.

Scripts timen met breakpoints

Om er achter te komen welk punt in een script traag is, maken we gebruik van aanvullende code om een script te timen. Je kunt de tijd meten tussen het begin en het eind van het script om zo uit te kunnen rekenen hoe lang een server over het uitvoeren van een script heeft gedaan. Als dit te lang is, kun je de eind-timer verplaatsen naar een hoger punt in de code. Hierdoor reken je een bepaald stuk script niet mee. Een specifiek punt in de code die gemeten wordt noemen we een breakpoint.

Als er door de timer te verplaatsen een groot verschil ontstaat in “execution time” is de kans zeer groot dat het probleem in een stuk script zit wat je uitgesloten hebt. Door verschillende punten in de code te proberen, kun je specifieker meten waar het probleem zit.

Breakpoints demonstratie

Deze techniek kan het best geïllustreerd worden aan de hand van een testcasus. In de casus gaan we uit van een script genaamd index.php dat een ander script “include” genaamd traag.php in de map includes.
De bestanden zien er als volgt uit:

index.php
<?php
/*** Simpel debug voorbeeld*//
* Haal tijd variabelen op */
$hours = date ("H");
$minutes = date ("i");
/* Controleer op de dagdelen */s
witch (true) 
{       
case ($hours >= 0 && $hours < 6):        
$begroeting = "Goedenacht!";        
break;    
case ($hours >= 6 && $hours < 12):        
$begroeting = "Goedemorgen!";        
break;    
case ($hours >= 12 && $hours < 18):        
$begroeting = "Goedemiddag!";        
break;    
case ($hours >= 18):        
$begroeting = "Goedenavond!";        
break;
}
/* Schrijf de begroeting uit */
echo $begroeting . "<br />";
/* Schrijf de tijd uit */
echo $hours . " : " . $minutes . "<br />";
/* Include ander bestand */
include ("includes/traag.php");
?>
includes/traag.php
<?php
/*** Simpel debug voorbeeld*//
* Wacht 5 seconden *
/sleep (5);
/* Schrijf Hoi! uit */
echo "Hoi!";
?>

In het bovengenoemde voorbeeld is vrij eenvoudig te zien waarom dit script traag zou zijn. In includes/traag.php wordt door het commando sleep(5) aangegeven dat het script 5 seconden moet “pauzeren”.
Om de vertraging in deze testcase toch te kunnen traceren, kun je het volgende gebruiken:
Je kunt het script timen om te zien waar het probleem zit. Begin door twee timer scripts aan te maken in de includes map. Noem deze before.php en after.php (voor de code, en na de code) en zet daar de volgende code in:includes/before.php

<?php
/*** Simpel timer voorbeeld*//
* Sla de start waarde op */
$DEBUG_SCRIPT_START_TIME = microtime (true);
/* Meld het starten van de het script */
echo "<hr>";
echo "START SCRIPT<br>";
echo "<hr>";
?>
includes/after.php
<?php
/*** Simpel timer voorbeeld*//
* Reken de tijdsduur uit */
$DEBUG_SCRIPT_EXECUTION_TIME = microtime (true) - 
$DEBUG_SCRIPT_START_TIME;
/* Meld het stoppen van het script en schrijf de tijdsduur uit */
echo "<hr>";
echo "END SCRIPT<br>";
echo "Execution time: " . 
$DEBUG_SCRIPT_EXECUTION_TIME;
echo "<hr>";
?>

Aanbrengen van de timers

Om de timers te gebruiken binnen de applicatie moeten ze nog wel eerst ingeladen worden. Omdat index.php het bestand is dat aangeroepen wordt en wat traag lijkt te zijn, begin je hiermee. Plaats op de eerste regel na “<?php” de volgende code:

include ("includes/before.php");

Op de regel voor “?>” plaats je de volgende code:

include ("includes/after.php");
/* Stop het script */
exit ();

Laat verder alles intact.

Meten van het script

Als we het script nu aanroepen in browser zal er iets als het volgende uitkomen:

START SCRIPT
Goedemiddag!      
12 : 04      
Hoi!
END SCRIPT       
Execution time: 5.0034561157227

Je kunt zien dat de execution time over de vijf seconden is. Dat lijkt erg veel. Verplaats nu het tweede breakpoint een stuk naar boven (bijvoorbeeld net na “}” ). Laad de pagina daarna opnieuw.
Als het goed is zal de uitvoer in de browser er nu als volgt uitzien:

START SCRIPT
END SCRIPT        
Execution time: 0.00013303756713867

Hoewel het script gedeeltelijk niet meer wordt uitgevoerd, zien we dat de execution time ruim 5 seconden is gedaald. De vertraging lijkt dus na het 2e breakpoint te komen (het stuk dat niet meer wordt uitgevoerd). Verplaats dit breakpoint nu naar de regel na echo $hours . ” : ” . $minutes . ”
“; en test de uitvoer opnieuw.
Je zult nu, als het goed is, het volgende in je browser zien:

START SCRIPT
Goedemiddag!          
12 : 36
END SCRIPT          
Execution time: 0.00013279914855957

De execution time lijkt nog steeds normaal. De enige functie die na het breakpoint nog uitgevoerd wordt, is het volgende:

/* Include ander bestand */
include ("includes/traag.php");

Dit is een functie die een ander bestand inlaadt (namelijk includes/traag.php). Het is dus hoogstwaarschijnlijk zo dat het probleem niet veroorzaakt wordt in index.php, maar door een bestand vanaf dat niveau. De test moet dus in dat bestand doorgezet worden.
Als je dit doet zul je zien dat sleep (5) de functie is die de vertraging veroorzaakt (dit is ook exact wat deze functie moet doen). Het verwijderen van deze functie zal de applicatie snel maken.

START SCRIPT
Goedemiddag!        
12 : 45        
Hoi!
END SCRIPT        
Execution time: 0.00016307830810547

Meer artikelen in de de categorie ‘Website debuggen’


40