Byte-New-RelicGastblogger: Bart ten Brinke, Retrosync

New Relic is een applicatie die meting verricht aan je website/webapplicatie. Het is begonnen in 2008 als een tool om de performance van Ruby on Rails te monitoren, maar ondertussen zijn eigenlijk alle denkbare talen en platformen aan New Relic toegevoegd.

Dat is natuurlijk heel mooi, maar dat maakt het voor nieuwe gebruikers ook vaak erg lastig om door alle mogelijkheden je weg te vinden. Als performance consultant maak ik sinds 2008 dankbaar gebruik van alle opties die New Relic biedt om problemen binnen een webapplicatie te identificeren en op te lossen.
In deze blogpost zal ik proberen om de, naar mijn mening, twee belangrijkste functies van New Relic uit te leggen, zodat hopenlijk snel duidelijk wordt waar voor jou de voordelen zitten.

APM:Transactions

Nu zul je misschien denken, mijn site doet het toch als ik de url intik? En verder houd ik hem in de gaten met pingdom en vertrouw ik op Byte dat hij in de lucht blijft. Dus wat moet ik nog meer weten?

Een veel voorkomende situatie is dat er een nieuwe versie van een webapplicatie wordt uitgerold. Vervolgens belt een klant op dat pagina X voor hem ineens onwerkbaar traag is geworden! Paniek! Wat moet je doen? Terugrollen naar de vorige versie? Of inloggen als de klant en proberen het probleem te reproduceren? Maar als dat al lukt, hoe kom je dan achter de oorzaak? Of ligt het gewoon aan de internetverbinding van de klant zelf?

In een dergelijke situatie is New Relic APM (Application Performance Monitoring) een erg krachtig middel. Op de Overview pagina kun je in 1 oogopslag zien of er in de afgelopen periode langzame pagina’s zijn geweest (Transactions genoemd).

Door door te klikken op de transaction krijg je vervolgens een uitsplitsing waar de tijd van het verzoek in zat. Zat de tijd in het wachten op een externe API? Was de database langzaam? Als je New Relic Pro hebt, kun je op dit punt zelfs ook nog doorklikken in de code van je eigen applicatie (Transaction Tracing). Welke database queries zijn er gedaan en hoe lang duurde deze? En welke code zorgde ervoor dat deze query überhaupt werd afgevuurd?

Op deze manier is het erg eenvoudig om tot de kern van het probleem te komen. Door de problematische transactie te vergelijken met gisteren of met de vorige release is vaak nog beter te bepalen welke wijziging aan de applicatie het probleem heeft veroorzaakt.

Een Transaction Trace

Een Transaction Trace

 

APM:Browser

Kijken naar de tijd die de server er over doet om een pagina te serveren is erg belangrijk, maar er is natuurlijk maar een kant van het verhaal. De gebruiker aan de andere kant van de internet lijn moet de pagina namelijk ook nog ophalen en op zijn scherm tonen. Niet al je klanten zullen, zoals jij op kantoor, gebruik maken van een desktop met een stevige bedrade internet verbinding om de site te bezoeken. Steeds meer mensen gebruiken hun telefoon of tablet met bijbehorende 3G verbindingen om webapplicaties te bezoeken. En ook steeds vaker vanuit het buitenland.

APM:Browser maakt gebruik van een stukje javascript dat de gebruiker laat meten hoe lang het duurt voordat alle onderdelen van de website zijn ingeladen: html, css, javascript. Ook wordt gemeten hoe lang het duurt om de pagina te renderen op het device. Iets wat bij bijvoorbeeld goedkope Androids een stuk langer kan duren dan je denkt. Zo ontdekte ik recent bij een klant dat het tonen van de mobile pagina in Frankrijk via Edge gemiddeld 20 seconden duurde. Dit terwijl in Nederland via 3G dezelfde pagina in minder dan twee seconden op het scherm stond. Na de nodige wijzingen aan de site konden we met New Relic ook objectief vaststellen dat de gemiddelde tijd in Frankrijk was afgenomen van 20 seconden naar 4 seconden. Je kan vast wel raden wat dit voor uitwerking had op de conversies in Frankrijk.

Browser trace: een breakdown van de page view

 

New Relic heeft naast deze twee functies natuurlijk nog veel meer mogelijkheden, maar alleen deze twee maakt de gehele suite al zijn geld dubbel en dwars waard. Het aloude meten is weten geldt ook nog steeds voor webapplicaties: als je niet weet wat er precies stuk is, dan kun je het ook niet maken.

Heb je nou met New Relic een probleem gevonden in je applicatie, maar heb je geen idee hoe je dit moet oplossen? Dan kun je uiteraard altijd met mij contact opnemen. We are all data nerds!

– Bart ten Brinke – info@retrosync.com

 

—–

De beide onderdelen die Bart omschrijft zijn beschikbaar via het New Relic – Pro account (Transaction Tracing en Real User Monitoring Details & Traces). 

Meer weten? Kijk op onze website of bel ons op 020 – 5216 222.

Meer lezen over New Relic?

 

 

Ook een gastblog schrijven? Laat het ons weten via support@byte.nl!

 

Scan je eigen Magento shop op veiligheidslekken

Related Post