New Relic APM is een krachtige tool die tot diep in de WordPress site doordringt om plugins, thema-templatebestanden, databasequery’s, externe oproepen of coderingsfouten te lokaliseren die voor prestatieproblemen zorgen op de websites van onze klanten.
Bij Kinsta zijn onze klanten vrij om hun eigen New Relic licentie toe te voegen, zodat ze kunnen profiteren van de krachtige mogelijkheden die deze tool biedt.
Als je hostingprovider geen integratie met New Relic aanbiedt, kan je dit zelf doen als je site in een privéomgeving wordt gehost.
Het aan de gang krijgen 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. In deze tutorial laten we je zien hoe je New Relic APM gebruikt om prestatieproblemen op je WordPress site te diagnosticeren en op te lossen.
Klaar om de nerd in je naar boven te halen? Aan de slag!
A Quick Overview of 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
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
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.
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
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 plugins en thema’s
Het tabblad plugins en thema’s laat je zien hoeveel PHP-verwerkingstijd de plugins en actieve thema’s verbruiken. Als een plugin of thema van je site een buitenproportionele hoeveelheid tijd in beslag neemt, kan deze pagina je helpen om snel de plugin of het thema te vinden die het probleem veroorzaakt.
Een woord van waarschuwing is op zijn plaats: het tabblad WordPress plugins 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 plugin 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.
Plugins kunnen traag werken vanwege een onjuiste configuratie, zoals een plugin die lidmaatschappen beheert die traag werkt doordat hij een onjuiste SMTP-poort gebruikt. Of een plugin 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 plugin te deactiveren, die je in dit tabblad met plugins 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
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.
Externe diensten
De meeste WordPress-websites vertrouwen op een aantal externe services:
- Updates voor plugins, thema’s en de WordPress-core die van wordpress.org en van de plugin- en thema-ontwikkelaars komen.
- Veel plugins integreren met externe API’s, zoals de afbeeldingsoptimalisatieplugin Smush van WPMU DEV (smushpro.wpmudev.org in bovenstaande screenshot).
- Chatplugins 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.
Foutanalyse
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.
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:
- De langzame transactie dupliceren.
- Zoek de transactie in de lijst met langzame transacties in New Relic.
- 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.
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.
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.
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 plugin Google Analytics Post Pageviews. De plugin 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.
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 plugin 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, omdat onze schaalbare virtuele machines in staat zijn om verschillende hoeveelheden belasting aan te kunnen. 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 een ruime hoeveelheid serverresources, dan is de volgende plek waar je wil kijken in je zoektocht om deze traagheid op te lossen het WordPress tabblad met plugins en thema’s, het tabblad External services en het tabblad Databases.
Hier zijn voorbeelden van algehele traagheid die kunnen worden gediagnosticeerd met behulp van deze tabs.
Algehele traagheid veroorzaakt door een plugin
Wanneer een plugin je gehele site vertraagt dan variëren de symptomen op basis van de activiteit die plugin uitvoert. In veel gevallen zal je echter merken dat een langzame plugin elke plugin 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 plugins van de site.
Je ziet meteen dat de plugin adinjector 15x zoveel tijd in beslag neemt als de op-een-na langzaamste plugin.
Wanneer je dergelijke data ziet, is het verleidelijk om te denken dat de plugin 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 plugins, een trage database of externe bronnen die langzaam antwoorden kunnen ook een oorzaak zijn van een trage plugin.
Als je dus een plugin 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 plugin 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.
De afbeelding hierboven is van dezelfde site als die van de eerder getoonde schermafbeelding van de plugins. 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 plugin 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 plugin die het probleem veroorzaakt. In plaats daarvan lijkt het alsof de plugin 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 plugin in kwestie te checken, wat suggereert dat de licentie van deze specifieke plugin mogelijk is verlopen.
We kunnen nu in ieder geval de eigenaar van deze site nu informeren dat de plugin 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 pluginlicentie 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:
Ga naar het tabblad Databases om een beter inzicht te krijgen in welke databasetabel of query het probleem veroorzaakt.
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.
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 PHP-prestatieknelpunten 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.
Jon is de Chief Operating Officer bij Kinsta en is dagelijks betrokken bij de sales-, klantenservice- en technische ondersteuningsteams van Kinsta. Jon is een familieman. Dus als hij niet koortsachtig op de toetsen van zijn laptop aan het tikken is, is hij meestal een van zijn kinderen aan het helpen met het repareren van een fiets of het opzetten van Netflix voor een ongeduldige kleuter.
Laat een reactie achter