Hoe wij New Relic gebruiken

New Relic is een bedrijf dat de performantie van jouw applicatie analyseert. Dit is interessant voor jou, maar New Relic is duur. Erg duur zelfs.

Als je optimaal gebruik weet te maken van New Relic daarentegen, is het elke eurocent waard. We tonen dit aan aan de hand van een duidelijk praktijkvoorbeeld.

Disclaimer: dit artikel probeert niet volledig te zijn, we raken slechts een klein deel van de functies van New Relic aan. Als je interesse gewekt is, kunnen we altijd meer informatie met je delen.

Het voorbeeld

Ik schrijf deze blog post in samenwerking met Inventis. Voor hen namen we onlangs de hosting van Blabloom over. Als we een bestaande website overnemen, doen we altijd een check van de performance. Enkele van de voornaamste taken:

• Kan de website overweg met de laatste versie van de software (b.v. PHP 5.6 of 7.0)?
• Is er mogelijkheid om de database te tunen?
• Gebruikt de server officiële softwarepakketten of is er een controlepaneel geïnstalleerd?
• Staat de website al achter Varnish of kunnen we dit implementeren samen met de webbouwer?

Voor de meeste websites volstaat dit om een behoorlijke verbetering te realiseren. Inventis was echter gemotiveerd om nog verder te gaan, en daar stonden wij natuurlijk direct voor klaar.

We gaven een introductie van Google Page Speed, waarmee Inventis zelf aan de slag ging, maar we gingen ook verder door New Relic te installeren.

Apdex

Om New Relic te kunnen begrijpen moeten we het begrip Apdex uitleggen. Apdex is een soort score die je website krijgt, die berekend wordt aan de hand van 2 factoren:

• De snelheid waarop je site door de server geserveerd wordt
• De snelheid waarop de site getoond wordt in de browser

New Relic noemt zijn Apdex zelf een 'satisfaction score'. Het is dus niet zomaar een getal, maar het duidt aan hoe tevreden of gefrustreerd de bezoekers van jouw website zijn.

De maximum Apdex is 1.0.

Probleem 1: Apdex vs Throughput

Op bepaalde momenten zien we dat de Apdex omlaag gaat:

Er is duidelijk een relatie met de throughput, dus het aantal opgevraagde pagina’s. Van het moment dat Apdex in het rode bereik komt, gaat New Relic ervan uit dat gebruikers ontevreden zijn.

Hier zie je de responstijden van de site op dat moment:

Het moment dat de Apdex 'in het rood' ging, is ook aangeduid op deze grafiek.

Op dit punt hadden we al door waar het schoentje wringt, dus laten we dit even bevestigen op dit klassieke server-overzicht:

Deze afbeelding toont een overzicht van de vitale parameters van de server tijdens het probleem. Dit leiden we eruit af:

• Er is 1 processor voorzien (rechts: 1 core)
• Deze processor zit zeker niet aan zijn maximum, maar springt af en toe wel omhoog tot aan 100%
• De load average (= het aantal processen dat zitten te wachten om uitgevoerd te worden) springt op het moment van de het probleem tot boven de 3. Voor een machine met 1 core is de load average bij voorkeur onder de 1 (omdat er steeds maar 1 proces uitgevoerd kan worden).

Dit is een server met database en web gecombineerd. Er moet dus constant geswitched worden tussen de verschillende taken. Strikt genomen is de server krachtig genoeg, echter merk je dat tijdens deze drukke momenten een kleine wachtrij ontstaat.

Oplossing 1

Denk nu niet dat we altijd alles oplossen door servers te verzwaren. Maar dit specifieke probleem kan je dus oplossen door het toevoegen van een 2de processor. De analyse van New Relic heeft ons geholpen om met grote precisie een diagnose te stellen.

Ziet er al heel wat beter uit, nietwaar :)

Om het verdere nut van New Relic aan te tonen, verlaten we hier even de case van Blabloom en zoeken we enkele duidelijkere voorbeelden.

Probleem 2 - Errors

Het eerste probleem is klassiek - een te lichte configuratie doet je site uiteraard naar adem happen. Dus dat hebben we al gefixed. Ben je nog mee? Wil je nog verder gaan?

Waarschuwing: hier stopt onze jurisdictie. Vanaf nu gaan we het hebben over JOUW code en die passen WIJ niet aan :) Maar we gaan je natuurlijk wel in de juiste richting wijzen. Niet opgeven nu, we zijn goed bezig.

Errors vertragen je website niet altijd. Maar je wil geen errors op je website, dat is duidelijk.

Je ziet duidelijk de ernst van de errors, dus in dit geval heb je heel veel warnings, maar ook enkele exceptions. Die warnings kan je natuurlijk fixen, maar wij zijn vooral geïnteresseerd in de exceptions. New Relic houdt alle details van de exception bij:

Wat hier erg interessant is, is dat je onmiddellijk een ticket/issue kan maken in je development tracker, b.v. Jira.

Probleem 3 - Trage transacties

Als je geen errors meer hebt en je server is sterk genoeg, dan ga je toch nog altijd wel merken dat sommige onderdelen traag reageren. Hier kan de krachtigste feature van New Relic je bij helpen. New Relic installeert immers een module in de programmeertaal van je website, en kan dus alle details geven die je nodig hebt.

Standaard zal New Relic details opslaan van alle requests naar je website die langer duren dan 2 seconden.

Bij transacties kan je het overzicht zien en sorteren op de traagste transacties:

Je ziet hierboven een Wordpress-website met Woocommerce plugin. Er wordt 82% van de tijd gespendeerd in de Woocommerce-plugin, dus dat is het waard om te onderzoeken. Onderaan rechts staat een lijst van transacties die langer geduurd hebben dan 2s:

Er zijn 4 voorbeelden waarbij het opvragen van een pagina langer heeft geduurd dan 21s. Zou die webshop nog iets verkopen? Hierop klikken we om de details te achterhalen:

Bovenstaand beeld geeft al erg veel informatie, ook weer gesorteerd op belangrijkheid. Dus 40% van de tijd spendeerden we in MetaDataFilter::draw_term_childs_select, 25% van de tijd in Minify_HTML::process. Dit is al interessante info, aan de namen kan je al veel afleiden. Maar je kan hier zelfs nog dieper in de details gaan kijken. Hier zie je bijvoorbeeld wat die draw_term_childs_select allemaal lijkt uit te vreten:

Het lijkt erop dat hier recursieve functie-oproepen gebeuren, die bovendien ook nogal wat database-toegang doen. Je kan zelfs de database query's zien als je wil:

Best wel wat query's om 1 pagina op te bouwen :)

Wat leren wij hier nu uit? Elk geval is uiteraard anders, maar in dit geval is het duidelijk dat er een probleem is. Mogelijke oplossingen hier zijn een slimme cache-strategie, een andere (meer efficiënte) plugin, ...

Het punt dat ik wil maken is dat New Relic de problemen uitstekend zichtbaar maakt. En alleen zo kan je naar een oplossing werken!

Wat kan New Relic nog meer?

We hebben hier maar een klein deel belicht van New Relic. En toch is het zo'n lang artikel geworden. Proficiat om zover te lezen!

Nog features van New Relic:

• Uitgebreide rapportering
• Analyse op wat er precies gebeurt in de browser: HTML-rendering, Javascript, ...
• Monitoring van je site en onderdelen ervan
• Insights, dashboards op maat over je applicatie

Actie!

Wil je ook New Relic proberen? Of heb je al New Relic en weet je niet goed hoe er het maximum uit te halen? Neem contact met ons op, wij helpen je verder.