New Relic APM är ett kraftfullt verktyg som djupdyker i en WordPress-webbplats för att peka ut plugins, tema-mallfiler, databasförfrågningar, externa anrop, eller kodningsfel som orsakar prestandaproblem på våra kunders webbplatser.
Kinsta’s kunder är fria att lägga till sin egen New Relic-licens så att de kan njuta av den kraftfulla synlighet som detta verktyg ger.
Om din hosting-leverantör inte erbjuder New Relic-integering kan du konfigurera detta själv om din webbplats hostas i en självhanterad privat miljö.
Men att få igång New Relic är bara början. Om du aldrig har använt New Relic APM (och kanske även om du har), kan du få problem med att få ut det mesta av detta kraftfulla verktyg. I den här handledningen visar vi hur du använder New Relic APM för att diagnostisera och åtgärda prestandaproblem på din WordPress-webbplats.
Redo att bli nördig? Nu sätter vi igång!
En snabb översikt över New Relic APM
Så vad är New Relic APM? För våra ändamål passar följande definition:
New Relic APM är en webbapplikation som ger detaljerad information om prestanda för din WordPress-webbplats.
Du installerar New Relic genom att lägga till ett tillägg till PHP. Tillägget lyssnar på varje begäran som behandlas av PHP och skickar sedan tillbaka den informationen till New Relic-panelen. New Relic organiserar sedan den informationen i en serie diagram och grafer som du kan använda för att diagnostisera webbplatsens prestandaproblem. Det är viktigt att notera att New Relic inte stöds på HHVM.
Låt oss ta en snabb tur genom New Relics primära datavisualiseringar.
Översikt
Översikten ger en snabb bild av webbplatsens övergripande prestanda. Du kommer inte att diagnostisera specifika problem från den här skärmen, men den praktiska sammanställningen som visar hur PHP, MySQL och externa anrop arbetar tillsammans kan peka dig i rätt riktning.
Läs mer om översiktssidan för APM.
Transaktioner
Fliken Transaktioner är den mest användbara fliken i New Relic.
Lär dig att älska fliken Transaktioner och du kommer att kunna gå ner på djupet i långsamma transaktioner för att identifiera databasanrop, externa resurser eller kod-flaskhalsar som saktar ner din webbplats. Av särskilt intresse i transaktionsvyn är listan över långsamma transaktioner. För att se listan, bläddra ner till nederdelen av fliken Transaktioner och titta i den nedre högra delen av sidan.
Här hittar du en lista över de långsammaste transaktionerna som fångas av New Relic. Vi kommer inte att spendera mer tid på det här avsnittet just nu, men lite senare förklarar vi hur du använder det här avsnittet för att diagnostisera problemen med din webbplats.
Läs mer om New Relic APM transaktionssida.
WordPress-krokar
Fliken WordPress-krokar ger en visualisering av den tid som förbrukas av alla PHP-funktioner som utlöses via WordPress-åtgärdskrokar. Denna information kan vara användbar för erfarna utvecklare som kan använda informationen för att arbeta bakåt från en överbelastad krok för att identifiera de funktioner som avfyras av kroken.
WordPressplugin och Teman
Fliken WordPressplugin och teman visar hur mycket PHP-bearbetningstid dina plugins och aktiva tema förbrukar. Om ett enda plugin eller din webbplats tema förbrukar en dramatiskt stor mängd tid, kan denna sida hjälpa dig att snabbt upptäcka vilket plugin eller tema som orsakar problemet.
Ett varningens ord är i ordning: Fliken WordPress-plugins och teman i New Relic är lätt att missbruka.
När man undersöker en webbplats prestandaproblem kan det vara frestande att som standard kontrollera den här fliken först och helt enkelt inaktivera det mest tidskrävande pluginet. Men att göra detta är att ignorera den värdefulla information som finns på andra ställen i New Relic. Det är som att behandla symtom snarare än att gräva i och hitta grundorsaken.
Plugins kan köras långsamt på grund av en felkonfiguration, såsom ett medlemssajthanteringsplugin som körs långsamt på grund av användningen av ett felaktigt SMTP-portnummer. Eller ett plugin kanske inte har avinstallerats korrekt. Detta är den typ av information som du förmodligen kan hitta genom att ner på djupet i en långsam transaktion på fliken Transaktioner, och du kommer aldrig att fixa det genom att helt enkelt inaktivera det långsammaste pluginet som rapporterats av New Relic.
Så bli bekväm med den här fliken, men inte till uteslutande av resten av informationen från New Relic.
Databaser
Fliken databaser låter dig identifiera databastabeller och typer av förfrågningar som förbrukar mest tid. New Relic knyter tillbaka denna information till de transaktioner som gör dessa förfrågningar. Du kan använda denna information för att identifiera databastabeller som kan kräva optimering och mallfiler som lägger en för stor belastning på databasen.
Externa Tjänster
De flesta WordPress-webbplatser är beroende av ett antal externa tjänster:
- Plugin, tema och kärnuppdateringar levereras från wordpress.org samt plugin- och tema-utvecklare.
- Många plugins integreras med APIs från tredje part, såsom WPMU DEVs Smush bildoptimeringsplugin (smushpro.wpmudev.org från skärmdumpen ovan).
- Chattplugins är i allmänhet levererade av externa tjänster.
- Många webbplatser är integrerade med sociala medie-plattformar för optimal presentation och prestanda när innehållet delas på dessa nätverk.
När någon av dessa externa tjänster slutar svara i tid kan det få hela din webbplats att krascha.
Fliken Externa tjänster låter dig snabbt se vilka externa tjänster som förbrukar mest tid. Du kan sedan använda den informationen för att avgöra om det är ett problem med hastighet (tjänsten svarar långsamt) eller kvantitet (det finns för många anrop till den externa källan) och arbeta på att lösa problemet.
Felanalys
Fliken felanalys rapporterar PHP-fel som uppstått när du laddar din WordPress-webbplats. Felen är grupperade i klasser, så att du snabbt kan se hur många olika typer av fel som genereras. Felen kopplas också tillbaka till de faktiska transaktionerna som genererade felen. Om du väljer ett specifikt fel kan du också se en full stack-spårning för transaktionen som genererade felet.
Tänk på felanalys som en bättre organiserad PHP-fellogg. Det kan vara ovärderligt när man försöker spåra filer som genererar PHP-fel och de transaktioner där dessa fel uppstår.
Felsöka sidor som laddas långsamt
Det vanligaste problemet vårt team använder New Relic för att felsöka är fallet med en viss sida eller process som tar en exceptionellt lång tid att ladda. När detta händer är fliken Transaktioner i New Relic APM nästan säkert den första platsen att bege sig till.
Processen du måste följa för att diagnostisera en långsamt laddande sida är ganska enkel:
- Duplicera den långsamma transaktionen.
- Hitta transaktionen i listan över långsamma transaktioner i New Relic.
- Granska transaktionsöversikten och spårningsdetaljer för att bestämma orsaken till den långsamma prestandan.
Låt oss titta på ett exempel på detta och hur New Relic kan användas för att diagnostisera problemet.
Steg 1: Duplicera transaktionen
Låt oss titta på ett exempel. I det här exemplet ser vår klient långsam laddning varje gång ett enskilt blogginlägg laddas. Alla andra sidor laddas normalt, men enskilda inlägg tar flera sekunder att ladda.
Så det första steget är att duplicera problemet. I det här fallet innebär det att besöka ett enda blogginlägg några gånger för att säkerställa att New Relic fångar all nödvändig data.
Observera: Om din webbplats använder sig av sidcachning, som är inbyggt i vår plattform här på Kinsta, måste du rensa cacheminnet mellan varje sidladdning. Annars kommer du ladda sidan från cacheminnet istället för att låta WordPress generera sidan.
Steg 2: Hitta den långsamma transaktionen
När du har duplicerat den långsamma transaktionen ett par gånger, gå till New Relic och välj fliken Transaktioner. Bläddra sedan ner tills du ser listan över långsamma transaktioner i den nedre högra delen av New Relic-panelen
Klicka på den transaktion du felsöker för att se detaljer.
Steg 3: Granska Transaktionsöversikt och spårningsuppgifter
När du har valt transaktionen visas en sammanfattning av transaktionen.
I sammanfattningen kan du se en ögonblicks-översikt över de komponenter som bidrog till transaktionens behandlingstid. I fallet med vår exempeltransaktion, ansvarar ett anrop till en extern resurs, www.googleapis.com, för 5 000 millisekunder av en transaktion som tog totalt 5 350 millisekunder att slutföra.
Även om detta är användbar information, kommer spårningsdetaljer-fliken att ge de detaljer vi behöver för att se exakt vad som händer.
Fliken spårningsdetaljer ger ett hierarkiskt steg-för-steg-vattenfall som visar funktionen, databasförfrågningar och externa anrop som PHP arbetar igenom när det genererar sidan.
I fallet med vår exempeltransaktion visar spårningsdetaljerna att ett anrop till en Google analytics-URL är vad som saktar ner processen. Om vi arbetar bakåt från den förfrågan initieras en PHP-funktion som heter gapp_get_post_pageviews. En snabb Google-sökning efter transaktionen visar att det är en del av Google Analytics Post Pageviews-pluginet. Detta plugin är installerat på webbplatsen och används för att lägga till en visningsräknare till en fastnålad rubriklist.
New Relic har bara tillåtit oss att isolera visningsräknaren i den fastnålade rubriklisten som den primära komponenten som bidrar till långsam laddning av enskilda blogginlägg på webbplatsen i fråga. Nu vet ägaren till den här webbplatsen exakt vilken komponent som hen ska titta på för att försöka lösa de långsamt laddade enskilda blogginläggen.
Fixa övergripande långsamhet
Den näst vanligaste typen av problem som vi felsöker för våra kunder är ett klagomål om att hela webbplatsen laddas långsamt. När varje transaktion tar lång tid att ladda, är det förmodligen en av dessa tre orsaker:
- Webbplatsen har för få serverresurser.
- En plugin eller det aktiva temat orsakar problem.
- Sajtdatabasen kämpar för att hålla jämna steg med mängden förfrågningar.
Server-resursproblem är sällsynta på Kinsta, eftersom våra skalbara virtuella datorer kan hantera olika mängder belastning. Men om webbplatsen har för lite CPU eller RAM, kan detta orsaka övergripande långsamhet som New Relic inte kommer att kunna tillskriva några enskilda resurser. Så om du ser övergripande långsamhet och New Relic indikerar att varje del av webbplatsen bidrar, kontrollera belastningen på din server för att se om en brist på serverresurser är boven i dramat.
Om din webbplats har tillgång till massor av serverresurser, då är nästa åtgärd för att diagnostisera övergripande långsamhet fliken WordPress-plugins och teman, fliken Externa tjänster, och fliken Databaser.
Här är exempel på övergripande långsamhet som kan diagnostiseras med var och en av dessa flikar.
Övergripande långsamhet orsakad av ett Plugin
När ett plugin orsakar övergripande långsamhet varierar symptomen beroende på aktiviteten som pluginet utför. Men i många fall kommer ett långsamt plugin att påverka varje sida på en WordPress-webbplats. När det gäller webbplatsen vars data du ser i bilden nedan observerades övergripande långsamhet på varje frontend-sida på webbplatsen.
Här är vad New Relic hade att säga om prestandan av pluginsen på webbplatsen.
Omedelbart kan du se att adinjector-pluginet förbrukar mer än 15 gånger den tid som det näst långsammaste pluginet.
När du ser data som denna kan det vara frestande att omedelbart avfärda pluginet som dåligt kodat eller på något sätt ineffektiv. Även om detta ibland är fallet är det inte alltid fallet. Plugin-felkonfiguration, databaslångsamhet, eller externa resurser som är långsamma att svara kan orsaka att ett plugin konsumerar en hel del tid.
Så när du ser att ett plugin svarar långsamt är det en bra idé att kontrollera flera andra skärmar i New Relic för att hitta ytterligare information. Transaktioner, databaser och externa resurser bör alla kontrolleras innan beslut fattas om ifall att inaktivera ett plugin är den bästa eller enda vägen framåt.
Övergripande långsamhet orsakad av externa tjänster
Om en webbplats förlitar sig på ett anrop till en extern tjänst för att generera sidvisningar, och den tjänsten slutar svara eller tar lång tid att svara, kan resultatet bli en WordPresswebbplats som helt slutar laddas.
Bilden ovan är från samma webbplats som producerade den långsamma plugin-skärmdumpen ovan. Som du kan se finns det en enskild extern tjänst som bidrar med en enorm mängd till den totala tiden av att vänta på externa tjänster.
Det här fallet visar varför det är nödvändigt att visa information i kombination innan man kommer fram till en slutsats. Tjänsten som anropas i detta fall är utvecklaren av pluginet som vi identifierade i det senaste steget.
Denna information lägger till viss nyansering av situationen. Det är inte koden för pluginet som är problemet, tydligen. Istället ser det ut som om pluginet gör massor av anrop till utvecklarens hemsida och dessa anrop, i kombination med varandra, förbrukar en hel del bearbetningstid.
Om vi tar saker ett steg längre och tittar på en långsam transaktion för den här webbplatsen kan vi se att det här externa anropet verkar kontrollera licensstatusen för pluginet i fråga, vilket tyder på att licensen för det här pluginet kan ha löpt ut.
Oavsett kan vi nu meddela ägaren till den här webbplatsen att adinjector-pluginet orsakar långsam prestanda, och den långsamma prestandan beror på upprepade anrop till utvecklarens webbplats för att kontrollera statusen för pluginets licens.
Övergripande långsamhet orsakad av en överväldigad databas
En dåligt optimerad databas kan orsaka övergripande långsamhet på en WordPresswebbplats. En optimering vi alltid rekommenderar är att konvertera din databas från MyISAM till InnoDB. I New Relic, kommer denna databasrelaterade långsamhet sannolikt att dyka upp på två ställen:
- Först ser du en enorm mängd MySQL-aktivitet i översikten.
- För det andra ser du en eller flera databastabeller som förbrukar mycket tid under fliken Databaser.
Med start i översiktsskärmen kan en webbplats med en kämpande databas se ut så här:
För att få ett bättre grepp om vilken databastabell eller förfrågning som orsakar problemet, bege dig till fliken databaser.
Fliken databaser pekar ut databastabeller och typer av förfrågningar som förbrukar mest tid. Om du väljer en av posterna i listan kan du se fler detaljer, inklusive några exempelförfrågningar.
I det här fallet pekar dina data på autoladdad data i wp_options-tabellen. Och visst, en snabb analys av wp_options-tabellen bekräftar att nästan 250 MB data autoladdas från denna tabell, vilket gör denna webbplats en riktigt bra kandidat för databasunderhåll och optimering. Kolla in vårt mer djupgående inlägg om hur du optimerar din wp_options-tabell och autoladdade data.
Sätt igång med felsökningen!
När du vet hur du använder det, kan New Relic vara ett värdefullt verktyg för att identifiera PHP prestandaflaskhalsar på din WordPress-webbplats. För att få ut det mesta av New Relic är det viktigt att du kan WordPress, förstår informationen som varje flik rapporterar och ser hur all information hänger ihop.
Vi har en annan intressant fallstudie om ämnet, så se till att du tar en titt: Felsökning av WordPress-prestandaproblem – Sånt händer-checklista
Har du några New Relic WordPress-tips? Vi skulle gärna höra dem nedan i kommentarerna.
Jon är Chief Operating Officer på Kinsta och är dagligen involverad i Kinstas försäljning, kundservice och tekniska supportteam. Han är en familjefar. Så när han inte febrilt trycker på tangenterna på sin bärbara dator brukar han hjälpa ett av sina barn att fixa en cykel eller ställa in Netflix för ett otåligt förskolebarn.
Lämna ett svar