Hier bij Kinsta maken onze Support Engineers elke dag gebruik van New Relic APM. Het is een krachtige tool die tot diep in de WordPress-site doordringt om plug-ins, themasjabloonbestanden, databasequery’s, externe oproepen of coderingsfouten te lokaliseren die voor prestatieproblemen zorgen op de websites van onze klanten.

We zijn er trots op dat we een developer-friendly beheerde WordPress-hosting zijn. Dat betekent dat we deze krachtige tool niet alleen maar voor onszelf willen houden. Op ons platform kunnen gebruikers hun eigen New Relic-licentie toevoegen om ook te genieten van dit krachtige systeem. Als je hostingprovider geen integratie met New Relic aanbiedt, kan je dit zelf doen als je site in een privé-omgeving wordt gehost.

Het starten van New Relic is echter nog maar het begin. Als je nog nooit de New Relic APM hebt gebruikt (en misschien ook wel als je dat wel hebt), dan maak je waarschijnlijk nog niet optimaal gebruik van deze krachtige tool. Het doel van deze tutorial is simpel: we laten je zien hoe je New Relic APM kan gebruiken om problemen met je WordPress-site op te lossen. Het wordt misschien af en toe een beetje nerdy, maar dan ben je in elk geval bij deze gewaarschuwd. Laten we beginnen!

A Quick Overview of New Relic APM

New Relic APM

New Relic APM

Dus wat is New Relic APM nou eigenlijk? Voor onze doeleinden past de volgende definitie:

Nieuwe Relic APM is een webtoepassing die gedetailleerde informatie levert over de prestaties van je WordPress-site.

Je installeert New Relic door een extensie toe te voegen aan PHP. Die extensie luistert naar elk verzoek dat door PHP wordt verwerkt en stuurt die informatie vervolgens terug naar het dashboard van New Relic. New Relic organiseert die informatie vervolgens in een reeks grafieken en diagrammen die je kan gebruiken om een diagnose te stellen van het prestatieprobleem van je website. Het is belangrijk op te merken dat New Relic niet wordt ondersteund op HHVM.

Laten we een korte rondleiding maken door de primaire datavisualisaties van New Relic.

Overzicht

Overzicht New Relic APM

Overzicht New Relic APM

Het overzicht biedt een simpel overzicht van de algehele prestaties van je site. Je kan in dit scherm geen specifieke problemen diagnosticeren, maar de handige compilatie laat zien hoe PHP, MySQL en externe aanvragen samenwerken en kan je in de juiste richting duwen.

Leer meer over de overzichtspagina van APM.

Transacties

Tabblad Transacties van New Relic

Tabblad Transacties van New Relic

Het tabblad Transactions is het nuttigste tabblad in New Relic.

De mogelijkheden zijn enorm. Met het Transactions-tabblad kan je dieper ingaan op trage transacties en database-aanvragen, externe resources, of knelpunten in codering identificeren die je site vertragen. In het Transactions-overzicht is de lijst met langzame transacties van bijzonder belang. Om deze lijst te zien, scrol je naar de onderkant van het Transactions-tabblad en kijk je rechtsonder de pagina.

Transactiesporen New Relic

Transactiesporen New Relic

Hier vind je ook een lijst met de langzaamste transacties die door New Relic zijn vastgelegd. We gaan nu even verder, maar we leggen later uit hoe je deze sectie kan gebruiken om problemen met je website te diagnosticeren.

Meer informatie over de Transactions-pagina van New Relic APM.

WordPress Hooks

WordPress hooks

WordPress hooks

Het tabblad met WordPress-hooks is een gevisualiseerde weergave van de tijd die wordt verbruikt door alle PHP-functies die worden geactiveerd door WordPress action hooks. Deze informatie kan nuttig zijn voor ervaren ontwikkelaars. Zij kunnen deze informatie gebruiken om achteruit te werken bij het identificeren van de functies die worden geladen vanuit een overbelaste hook.

WordPress plug-ins en thema’s

WordPress plug-ins en thema's

WordPress plug-ins en thema’s

Het tabblad plug-ins en thema’s laat je zien hoeveel PHP-verwerkingstijd de plug-ins en actieve thema’s verbruiken. Als een plug-in of thema van je site een buitenproportionele hoeveelheid tijd in beslag neemt, kan deze pagina je helpen om snel de plug-in of het thema te vinden die het probleem veroorzaakt.

Een woord van waarschuwing is op zijn plaats: het tabblad WordPress plug-ins en thema’s is het makkelijkst om verkeerd te gebruiken.

Bij het onderzoeken naar problemen met performance kan het verleidelijk zijn om dit tabblad als eerste te controleren en de meest belastende plug-in te deactiveren. Hiermee negeer je echter wel de waardevolle informatie die elders in New Relic gevonden kan worden. In feite behandel je de symptomen in plaats van de oorzaak.

Plug-ins kunnen traag werken vanwege een onjuiste configuratie, zoals een plug-in die lidmaatschappen beheert die traag werkt doordat hij een onjuiste SMTP-poort gebruikt. Of een plug-in is mogelijk niet correct verwijderd. Dit is het soort informatie dat je waarschijnlijk zou kunnen verkrijgen door je te verdiepen in de langzame transacties in het transactie-tabblad, maar die je nooit zou kunnen oplossen door de langzaamste plug-in te deactiveren, die je in dit tabblad met plug-ins tegenkomt.

Zorg dat je vrienden wordt met dit tabblad, maar laat deze vriendschap niet ten koste gaan van de andere informatie die door New Relic wordt verstrekt.

Databases

New Relic MySQL overzicht

New Relic MySQL overzicht

In het tabblad Databases kan je de databasetabellen en query-soorten identificeren die het meest tijdrovend zijn. New Relic koppelt deze informatie aan de transacties die deze query’s aanvragen. Je kan deze informatie gebruiken om de databasetabellen te identificeren die mogelijk moeten worden geoptimaliseerd, maar je kan hiermee ook sjabloonbestanden vinden die een te grote belasting op je database leggen.

Leer meer over de databasepagina van New Relic APM.

Externe diensten

New Relic externe diensten

New Relic externe diensten

De meeste WordPress-websites vertrouwen op een aantal externe services:

  • Updates voor plug-ins, thema’s en de WordPress-kern die van wordpress.org en van de plug-in- en thema-ontwikkelaars komen.
  • Veel plug-ins integreren met externe API’s, zoals de afbeeldingsoptimalisatieplug-in Smush van WPMU DEV (smushpro.wpmudev.org in bovenstaande screenshot).
  • Chatplug-ins worden meestal aangedreven door externe services.
  • Veel sites zijn geïntegreerd met sociale mediaplatforms voor optimale presentatie en prestaties wanneer content op die netwerken wordt gedeeld.

Wanneer een van deze externe diensten niet binnen een redelijk tijdsbestek reageert, kan je hele website tot stilstand komen.

Het tabblad externe diensten stelt je in staat om makkelijk de externe diensten eruit te pikken die het meeste tijd verbruiken. Je kan deze informatie vervolgens gebruiken om te bepalen of het een probleem is met snelheid (de service reageert langzaam) of kwantiteit (er zijn te veel aanvragen naar de externe bron en het probleem oplossen.

Lees meer over de pagina Externe diensten van New Relic APM.

Foutanalyse

Foutanalyse New Relic

Foutanalyse New Relic

Het tabblad Foutanalyse meldt de PHP-fouten die zijn opgetreden tijdens het laden van je WordPress-site. De fouten zijn gegroepeerd in classes, zodat je snel kan zien hoeveel verschillende soorten fouten worden gegenereerd. De fouten worden ook gekoppeld aan daadwerkelijke transacties die de errors veroorzaken. Als je een specifieke fout selecteert kan je de volledige stack-trace van de transactie die de fout genereerde zien.

Je kan foutanalyse het beste beschouwen als een beter georganiseerd PHP-foutenlogboek. Dit kan van onschatbare waarde zijn wanneer je bestanden probeert op te sporen die PHP-fouten genereren en de transacties waarbij die fouten optreden.

Meer over Foutanalyse van New Relic..

Langzaam ladende pagina’s debuggen

Waar ons team New Relic het vaakst voor gebruikt is het debuggen van een specifieke pagina of proces waarvan het laden uitzonderlijk lang duurt. Wanneer dit gebeurt, is het tabblad Transactions in New Relic APM vrijwel altijd de eerste plaats die we bezoeken.

Het proces dat je moet doorlopen om een langzaam ladende pagina te diagnosticeren is vrij eenvoudig:

  1. De langzame transactie dupliceren.
  2. Zoek de transactie in de lijst met langzame transacties in New Relic.
  3. Bekijk het transactieoverzicht en zoek in de details naar de oorzaak van de trage prestaties.

Laten we een voorbeeld gebruiken om aan te geven hoe we dit proces kunnen volgen om het probleem te diagnosticeren.

Stap 1: De transactie dupliceren

In dit voorbeeld ziet onze klant dat artikelen er erg lang over doen om te laden. Alle andere pagina’s laden normaal, maar het laden van afzonderlijke artikelen duurt enkele seconden.

De eerste stap is om het probleem te dupliceren. In dit geval betekent dit dat we een aantal keren een artikel bezoeken om te zorgen dat New Relic de benodigde data vastlegt.

Opmerking: als je site gebruikmaakt van paginacaching – iets dat standaard ingebouwd is in het Kinsta-platform – moet je de cache legen na het laden van elke pagina. Als je dat niet doet, laad je de pagina uit de cache in plaats van dat WordPress de pagina genereert.

Stap 2: Zoek de langzame transactie

Nadat je de langzame transactie hebt gedupliceerd, ga dan naar New Relic en selecteer het tabblad Transactions. Scrol vervolgens omlaag tot je de lijst ziet met langzame transacties, deze vind je rechtsonder in het New Relic-dashboard.

Langzame transacties in New Relic

Langzame transacties in New Relic

Klik op de transactie die je aan het debuggen bent om de details te zien.

Stap 3: Transactieoverzicht en traceergegevens bekijken

Nadat je de transactie hebt geselecteerd, krijg je een samenvatting van de transactie te zien.

Samenvatting langzame transactie

Samenvatting langzame transactie

De samenvatting toont je een beknopt overzicht van de componenten die bijdroegen aan de verwerkingstijd van de transactie. In de casus van onze voorbeeldtransactie is een oproep naar een externe bron, www.googleapis.com, verantwoordelijk voor 5.000 milliseconden van de totale transactietijd van 5.350 milliseconden.

Hoewel dit nuttig informatie is, geeft het tabblad Trace Details de gegevens die nodig zijn om precies te zien wat er gebeurt.

Langzame transactie trace details

Langzame transactie trace details

Het tabblad Trace Details toont een hiërarchische stapsgewijze watervalanalyse met daarin de functie, databasequery’s en externe oproepen die PHP doorloopt tijdens het genereren van de pagina.

In onze voorbeeldtransactie maakt Trace Details het duidelijk dat een oproep naar de URL van Google Analytics het hele proces vertraagt. Als we vanaf dat verzoek achteruit werken, dan zien we dat deze is gestart door een PHP-functie genaamd gapp_get_post_pageview. Een snelle Google-zoekopdracht vertelt ons dat deze transactie onderdeel is van de plug-in Google Analytics Post Pageviews. De plug-in is op de site geïnstalleerd en wordt gebruikt om een weergaveteller toe te voegen aan een sticky headerbalk.

New Relic heeft ons dus in staat gesteld om de weergaveteller in de sticky headerbalk als ‘dader’ aan te wijzen die verantwoordelijk is voor het langzame laden van de artikelen van de site in kwestie. Nu weet de eigenaar van de site precies op welk onderdeel hij zich moet richten om de trage laadtijden van zijn blogartikelen op te lossen.

Downtime en WordPress problemen? Kinsta is de hosting oplossing speciaal ontworpen om jou tijd te besparen! Bekijk onze kenmerken

Algemene traagheid oplossen

Het tweede meest voorkomende soort probleem is dat klanten ons benaderen omdat de hele site langzaam wordt geladen. Wanneer elke transactie veel tijd in beslag neemt, dan is waarschijnlijk een van deze drie dingen aan de hand.

  • De site heeft te weinig server-resources.
  • Een plug-in of het actieve thema veroorzaakt problemen.
  • De database van de site kan niet opboksen tegen het aantal query’s.

Bij Kinsta zijn problemen met server-resources zeldzaam. We wijzen CPU en RAM toe als dat nodig is en beheren de algehele belasting van onze machines zo dat er voldoende server-resources beschikbaar zijn als je sites ze nodig hebben. Als je site echter te weinig CPU en RAM heeft, dan kan dit een algehele traagheid veroorzaken die New Relic niet op een enkele bron kan pinpointen. Als je dus algehele traagheid ervaart en New Relic geeft aan dat elk deel van je site daaraan bijdraagt, kijk dan naar hoe je server belast wordt om te zien of een tekort aan server-resources hieraan schuldig is.

Als je site beschikt over veel server-resources, dan is de volgende plek waar je wil kijken in je diagnose de tabbladen WordPress Plugins/Themas, de External Services en de Databases.

Hier zijn voorbeelden van algehele traagheid die kunnen worden gediagnosticeerd met behulp van deze tabs.

Algehele traagheid veroorzaakt door een plug-in

Wanneer een plug-in je gehele site vertraagt dan variëren de symptomen op basis van de activiteit die plug-in uitvoert. In veel gevallen zal je echter merken dat een langzame plug-in elke plug-in op een WordPress-site beïnvloedt. In het geval van de site waarvan je de data hieronder ziet, dan zagen we dat de site traag was op elke front-end pagina van de site. Dit is wat New Relic had te zeggen over de prestaties van de plug-ins van de site.

WordPress plug-ins

WordPress plug-ins

Je ziet meteen dat de plug-in adinjector 15x zoveel tijd in beslag neemt als de op-een-na langzaamste plug-in.

Wanneer je dergelijke data ziet, is het verleidelijk om te denken dat de plug-in slecht gecodeerd is of op een andere manier ineffectief is. Hoewel dit soms inderdaad het geval is, is dit niet altijd zo. Verkeerde configuratie van plug-ins, een trage database of externe bronnen die langzaam antwoorden kunnen ook een oorzaak zijn van een trage plug-in.

Als je dus een plug-in tegenkomt die langzaam reageert, is het een goed idee om ook andere tabbladen van New Relic door te spitten om aanvullende informatie te vinden. De transacties, databases en externe bronnen moeten allemaal worden gecontroleerd voordat besloten kan worden dat deactivatie van de plug-in de enige of beste oplossing is.

Algehele traagheid veroorzaakt door externe diensten

Als een site afhankelijk is van een oproep naar een externe dienst bij het genereren van een pagina, en die dienst reageert niet of traag, dan kan het resultaat zijn dat een WordPress-site helemaal niet meer laadt.

Top 5 externe diensten

Top 5 externe diensten

De afbeelding hierboven is van dezelfde site als die van de eerder getoonde schermafbeelding van de plug-ins. Zoals je ziet is er één externe dienst die overmatig bijdraagt aan de totale tijd die wordt besteed aan het wachten op externe diensten.

Deze casus laat zien waarom het noodzakelijk is om gecombineerde gegevens te bekijken voordat je tot een conclusie komt. De dienst die wordt aangeroepen, is de ontwikkelaar van de plug-in die we in de vorige stap identificeerden.

Deze informatie voegt wel enige nuance toe aan de situatie. Het is dus niet per se de code van de plug-in die het probleem veroorzaakt. In plaats daarvan lijkt het alsof de plug-in veel oproepen naar de website van de ontwikkelaar doet, en deze oproepen kosten veel uitvoeringstijd.

Als we nog een stap verder gaan en we naar de langzame transactie voor deze site kijken, dan zien we dat de externe oproep als doel heeft om de licentiestatus van de plug-in in kwestie te checken, wat suggereert dat de licentie van deze specifieke plug-in mogelijk is verlopen. We kunnen nu in ieder geval de eigenaar van deze site nu informeren dat de plug-in adinjector de trage prestaties veroorzaakt en de trage prestaties te wijten zijn aan de herhaalde oproepen aan de website van de ontwikkelaar om de status van de plug-inlicentie te controleren.

Algehele traagheid veroorzaakt door een overbelaste database

Een slecht geoptimaliseerde database kan ook een algehele traagheid op een WordPress-site veroorzaken. Een optimalisatie die we altijd aanbevelen is om je database te converteren van MyISAM naar InnoDB. In New Relic zal traagheid door een overbelaste database waarschijnlijk op twee plaatsen verschijnen:

  • Allereerst zie je waarschijnlijk een grote hoeveelheid MySQL-activiteit in het overzicht.
  • Ten tweede zie je dat een of meerdere databasetabellen veel tijd verbruiken in het tabblad Databases.

Als we beginnen met het overzichtsscherm, dan ziet een overbelaste database er vaak ongeveer zo uit:

Transactietijd web

Transactietijd web

Ga naar het tabblad Databases om een beter inzicht te krijgen in welke databasetabel of query het probleem veroorzaakt.

Overzicht MySQL

Overzicht MySQL

De tab Databases geeft de tabel en het type query aan die het meeste tijd in beslag neemt. Als je een van de items in de lijst selecteert, krijg je meer details te zien, waaronder enkele voorbeeldquery’s.

Langzame query - wp_options tabel

Langzame query – wp_options tabel

In deze casus wijst alles erop dat het probleem wordt veroorzaakt door autoloaded data in de tabel wp_options. En ja hoor, een vlugge analyse van de wp_options-tabel bevestigt dat bijna 250MB aan data automatisch worden geladen vanuit deze tabel, wat deze site een uiterst geschikte kandidaat maakt voor een flinke portie database-onderhoud en -optimalisatie. Bekijk ons gedetailleerde artikel over het optimaliseren van je wp_options-tabel en autoloaded data.

Tijd om te debuggen!

Zodra je eenmaal door hebt hoe New Relic kan gebruiken, is het een waardevolle tool om knelpunten in de prestaties van je WordPress-website te identificeren. Om het maximale uit New Relic te halen, is het van cruciaal belang dat je WordPress kent, de informatie begrijpt die in elk tabblad te vinden is en hoe de informatie die je tegenkomt in relatie staat tot elkaar.

We hebben ook nog een andere interessante casestudy over het onderwerp, dus neem vooral een kijkje: Debugging WordPress Performance Issues – Stuff Happens Checklist.

Heb jij nog New Relic WordPress-tips? We horen ze graag in de reacties.


Als je dit artikel leuk vond, dan zul je gek zijn op Kinsta’s WordPress hosting platform. Of het nu gaat om het versnellen van jouw website of het krijgen van 24/7 support van ons ervaren WordPress-team. Onze door Google Cloud aangedreven infrastructuur is gericht op automatische schaalbaarheid, prestaties en beveiliging. Laat ons jou het Kinsta verschil tonen! Bekijk onze pakketten