Het in kaart brengen en debuggen van code

Het in kaart brengen en debuggen van code

Als u een development project aanneemt met bestaande code die was geschreven als onderdeel van een voorgaand project, dan heeft u waarschijnlijk een profiler of debugger gebruikt om de “bottlenecks” te vinden. De oorzaak van een voorkomend probleem hoeft niet altijd bij de developers te liggen.

Er zijn vele verschillende manieren om code te debuggen en dit is sterk afhankelijk van de omstandigheden. In ons geval zie je vaak dat “fouten” in de code aan het licht komen als het gebruik van de site enorm toeneemt. Dit is de reden waarom nieuwe architectuur voorzien moet zijn op de huidige, maar ook op de toekomstige behoeften. Maar dit is waarschijnlijk een onderwerp voor een ander artikel.

Wat is Blackfire?

Blackfire is een project performance management tool die wordt gebruikt bij het debuggen van code in alle project fases: ontwikkeling, testen, productie.

Waarom Blackfire?

Er is géén server load. Blackfire is alleen actief zodra geactiveerd, en ook alleen maar in de huidige sessie. Dit is erg belangrijk, met name wanneer je een functionaliteit of een pagina moet testen en debuggen, terwijl deze pagina live in productie is.

Blackfire heeft nuttige tools om testen uit te voeren vanaf de command line, en daarnaast via een plug-in in je browser. Een bonus is de SDK voor integratie in de applicatiecode waar je alles kunt debuggen. Er zijn veel extra functies: autorun van tests, integratie met Gitlab, GitHub, Bitbucket, Newrelic, Slack, Hipchat en andere opties die helpen om code te debuggen, te testen en code te verbeteren.

Waarom code debuggen?

Als ontwikkelaar ben je, naast de architectuur van de applicatie, ook geïnteresseerd in de performance.  Is  de code foutloos ontworpen? En wat is het gedrag in specifieke of onverwachtse situaties.

Welke belangrijke parameters meten de performance van de code?

I/O Wait – de tijd dat de HDD aan het werk is. Als de applicatie met een file systeem werkt dan is inzicht in de verhouding tussen read/write/search content erg nuttig. Met Magento 1 of 2 kan je de belasting van de HDD zien als de XML files worden aangesproken. Een gevolg is dan om SSD te gebruiken.

CPU Time – processor’s time.

Geheugen – de hoeveelheid RAM die de applicatie verbruikt. Deze optie kan om verschillende redenen vergroten of verkleinen. Functies die met name geheugen capaciteit verslinden: Unserialize, array_value, base64_decode etc. Deze opsomming is niet volledig maar geeft een indruk en is afhankelijk van de applicatie.

Netwerk – de hoeveelheid informatie die wordt verstuurd en ontvangen over het internet.

HTTP – requests. Als een applicatie externe services gebruikt zoals SOAP, REST dan helpt dit om “slow requests” te identificeren. Een veelvoorkomende oorzaak van de “slow code” is het gebruik van 3rd party services die niet onder uw eigen controle staan. Sommige hiervan stoppen gewoon met functioneren of zijn erg traag met als resultaat dat ook uw applicatie traag performed.

SQL Queries – hier bevindt zich waarschijnlijk de grootste kwetsbaarheid in uw code, met name als u iedere query in detail moet analyseren, en de impact op de applicatie en het systeem als geheel. De afweging die zal moeten worden gemaakt is of de query moet worden geoptimaliseerd of dat deze volledig ontzien moet worden.

TimeLine is een tool voor het visueel analyseren van de functionaliteit

a place for a picture

Voorbeeld van de SDK connectie voor het debuggen van de check-out functionaliteit in Magento

Volledige documentatie en opties vindt u hier.

De installatie van de SDK slaan we hier over, omdat deze informatie beschikbaar is in de documentatie, zie svp hierboven. Het enige wat we wel willen vermelden is dat alle erterne libraries die we gebruiken voor Magento 1, gekopieerd worden naar de vendor folder.

In meer dan 90% van onze klantcases hebben merchants de voorkeur om een check-out oplossing van een 3rd party te gebruiken. Dit komt niet door de functionele beperkingen van de “native” check-out in Magento, maar door de hogere gebruiksvriendelijkheid en betere klantbeleving van deze 3rd party check-out plug-ins.

Het voorbeeld hieronder heeft betrekking op de standard check-out oplossing in Magento. U kunt deze aanpak voor iedere module gebruiken.

a place for a picture

We installeren de Blackfire library, en configureren het profiel. In plaats van “client-id” en “client-token”, moeten hier de gegevens worden ingevoerd die Blackfire meegeeft. (voor een proef-versie moet u zich registreren).

Begin van het profiel $probe = $blackfire-> createProbe();

Eind van het profiel = $blackfire-> endProbe ($probe);

Conclusie

Blackfire helpt u om “bottlenecks” in uw code te vinden. Het feit dat u deze tool kunt gebruiken in de productie omgeving is het voornaamste voordeel. Het gebruik van xDebug is niet mogelijk vanwege de grote overhead, en tevens het gebrek aan UI ter identificatie, zoeken en analyseren van de gebruikte functionaliteiten. Er zijn ook gratis tools verkrijgbaar op het web, maar deze bieden niet de vereiste informatie die wij noodzakelijk achten. Het vinden van een probleem neemt veel tijd in beslag en daar komt bij dat gedurende deze tijd de server wordt belast.

Andere interessante tools zijn Newrelic en Tideways, maar deze zijn meer gericht op monitoring en niet zozeer op debugging. In een volgend artikel kunnen we u hierover meer informatie geven.

Het is belangrijk om debugging, monitoring en testen van elkaar te onderscheiden.

Er zijn passieve en actieve tools om errors te detecteren. Deze hebben allemaal hun eigen voor- en nadelen.

Als u bent geïnteresseerd in het debuggen en testen van uw code, neem dan contact met ons op via de site.