Bij Websteen ontwikkelen we snelle, robuuste webapplicaties met het Laravel framework. Een handig hulpmiddel daarbij is de Laravel Debugbar, een third party tool die realtime laat zien wat er op een pagina gebeurt.
- Welke objecten zijn geladen?
- Hoeveel blade templates worden geladen?
- Welke queries worden er op de database afgevuurd?
- Hoe lang duurt het voordat de database resultaten terugstuurt?
- Wat staat er in de request?
Werken met de Debugbar
We hebben de Laravel Debugbar geïnstalleerd op onze ontwikkelomgeving en daarmee is de bar standaard beschikbaar op de pagina. Het is niet dat we er dagelijks mee bezig zijn, maar als we zien dat een bepaalde pagina traag is of als we denken een applicatie te kunnen optimaliseren, dan duiken we erin.
Met name de volgende metrics zijn daarbij interessant:
| Models | Het aantal objecten (rijen uit de database) dat de pagina gebruikt. Halen we niet te veel modellen op die we toch niet gebruiken? | |
| Queries | Het aantal statements dat we naar de MySQL server sturen. Hoeveel zijn het er, en hoe lang duren ze? | |
| Tijd | De totale tijd van de request. | |
| Memory Usage |
De maximale hoeveelheid memory die tijdens de request is gebruikt. Deze optie is vooral handig omdat we op onze lokale omgeving meer memory hebben dan op de productieserver. Deze optie is vooral handig omdat we op onze lokale omgeving meer memory hebben dan op de productieserver. |
Het belang van performance testen
Een lokale ontwikkel- of testomgeving kan sneller zijn dan een productieomgeving. Dat komt omdat er maar één applicatie op draait en er geen sprake is van concurrent users of hoge load. Daardoor lijkt de performance al snel goed. Het risico bestaat daardoor dat problemen pas in productie worden opgemerkt en dan is het te laat. Daarom is het belangrijk om al tijdens ontwikkeling scherp te zijn op mogelijke performance issues.
Enkele bekende valkuilen zijn:
- Het N+1 probleem:
Als je een object ophaalt dat een relatie heeft met andere objecten, worden alle objecten standaard opgehaald met een aparte query. Dat betekent dat voor het opvragen van een lijst met 1000 klanten incl. adres, 1001 queries gedaan worden: één voor de klantenlijst en één voor elk klantadres. Al die queries kunnen het systeem traag maken, zeker als er meerdere requests tegelijk worden afgehandeld. Daarom gebruiken wij in dit soort gevallen de eager loading functionaliteit van Laravel. Daarmee kun je de 1000 adres-queries vervangen door een enkele query en hou je uiteindelijk maar twee queries over. Eentje voor de lijst met klanten en een voor de klantadressen. - Problemen met indexatie
Zelfs een perfect geschreven query komt nauwelijks vooruit als de onderliggende tabel niet goed geïndexeerd is. Dat geldt vooral als het om grote tabellen gaat: hoe meer kolommen en rijen, hoe trager de query. Het indexeren van de juiste kolommen, zal de performance enorm verbeteren.
Tenslotte
Dankzij de Laravel Debugbar kunnen we potentiële performanceproblemen snel detecteren en uit de weg ruimen. Meer weten, of een keer komen kijken hoe het precies werkt? Je bent altijd welkom voor een kop koffie!
