New Relic APM er et kraftfuldt værktøj, der dykker ned i de indre funktioner på et WordPress-websted for at lokalisere plugins, temaskabelonfiler, databaseforespørgsler, eksterne opkald eller kodningsfejl, der forårsager ydeevneproblemer på dine websteder.
Hos Kinsta kan vores kunder frit tilføje deres egen New Relic-licens, så de kan nyde den kraftfulde synlighed, som dette værktøj giver.
Hvis din hostingudbyder ikke tilbyder New Relic-integration, kan du selv konfigurere det, hvis dit websted hostes i et selvadministreret privat miljø.
Men at få New Relic til at køre er kun begyndelsen. Hvis du aldrig har brugt New Relic APM (og måske endda hvis du har), kan du kæmpe for at få mest muligt ud af dette kraftfulde værktøj. I denne vejledning viser vi dig, hvordan du bruger New Relic APM til at diagnosticere og løse ydeevneproblemer på dit WordPress-websted.
Klar til at blive nørdet? Lad os komme igang!
Et hurtigt Overblik over New Relic APM
Så hvad er New Relic APM? Til vores formål passer følgende definition:
New Relic APM er en webapplikation, der indeholder detaljerede oplysninger om ydeevnen på dit WordPress-site.
Du installerer New Relic ved at tilføje en udvidelse til PHP. Denne udvidelse lytter til enhver anmodning, der behandles af PHP og sender derefter disse oplysninger tilbage til det nye Relic-betjeningspanel. New Relic organiserer derefter disse oplysninger i en række diagrammer og grafer, som du kan bruge til at diagnosticere dit websites effektivitetsproblem. Det er vigtigt at bemærke, at New Relic ikke understøttes på HHVM.
Lad os tage en hurtig tur gennem New Relics primære datavisualiseringer.
Oversigt
Oversigten giver et hurtigt snapshot af den samlede ydelse på dit website. Du diagnosticerer ikke specifikke problemer fra denne skærm, men den praktiske kompilering, der viser, hvordan PHP, MySQL og eksterne opkald fungerer sammen, kan pege dig i den rigtige retning.
Lær mere om APM-oversigtssiden.
Transaktioner
Fanen Transaktioner er den mest nyttige fane i New Relic.
Lær at elske fanebladet Transaktioner, og du vil være i stand til at uddybe langsomme transaktioner til at identificere databasekald, eksterne ressourcer eller kode-flaskehalse, der bremser dit website. Af særlig interesse inden for transaktionsvisningen er listen over langsomme transaktioner. For at se listen skal du rulle ned til bunden af fanen Transaktioner og se i nederste højre del af siden.
Her finder du en liste over de langsomste transaktioner, der er fanget af New Relic. Vi vil ikke bruge mere tid på dette afsnit lige nu, men lidt senere forklarer vi, hvordan du bruger denne sektion til at diagnosticere dit websites onde.
Lær mere om siden New Relic APM-transaktioner.
WordPress Hooks
Fanen WordPress hooks giver en visualisering af den tid, der forbruges af alle PHP-funktioner, der udløses via WordPress action hooks. Denne information kan være nyttig for erfarne udviklere, der kan bruge oplysningerne til at arbejde baglæns fra en overbelastet krog for at identificere de funktioner, der fyres af krogen.
WordPress-Plugins og Temaer
Fanen WordPress-plugins og temaer viser dig, hvor meget PHP-behandlingstid plugins og det aktive tema bruger. Hvis et enkelt plugin eller dit site-tema bruger en dramatisk overdreven mængde tid, kan denne side hjælpe dig med hurtigt at få øje på det plugin eller det tema, der forårsager problemet.
Et forsigtighedsord er i orden: fanen WordPress-plugins og temaer i New Relic er den nemmeste at misbruge.
Når man undersøger et websites præstationsproblem kan det være fristende at standard kontrollere denne fane først og blot deaktivere det mest tidskrævende plugin. At gøre dette er imidlertid at ignorere de værdifulde oplysninger, der findes andre steder i New Relic. Det ligner behandling af symptomer snarere end at grave i og finde den grundlæggende årsag.
Plugins kører muligvis langsomt på grund af et fejlkonfigurationsproblem, f.eks. et plugin for medlemskabsadministration, der kører langsomt på grund af brugen af et forkert SMTP-portnummer. Eller et plugin er måske ikke blevet afinstalleret korrekt. Dette er den slags information, du sandsynligvis kan udlede ved at bore ind i en langsom transaktion i fanen Transaktioner, og du vil aldrig rette ved blot at deaktivere det langsomste plugin, som rapporteret af New Relic.
Så vær komfortabel med denne fane, men ikke med udelukkelsen af resten af oplysninger fra New Relic.
Databaser
Fanen databaser giver dig mulighed for at identificere databasetabeller og typer af forespørgsler, der tager mest tid. New Relic binder disse oplysninger tilbage til de transaktioner, der fremsætter disse forespørgsler. Du kan bruge disse oplysninger til at identificere databasetabeller, der muligvis kræver optimering og skabelonfiler, der placerer en stor størrelse på databasen.
Eksterne Tjenester
De fleste WordPress-websites er afhængige af en række eksterne tjenester:
- Plugin-, tema- og kerneopdateringer leveres fra wordpress.org samt plugin- og temaudviklere.
- Mange plugins integreres med tredjeparts API’er, såsom WPMU DEVs Smush-billedoptimeringsplugin (smushpro.wpmudev.org fra skærmbilledet ovenfor).
- Chat-plugins drives normalt af eksterne tjenester.
- Mange websites er integreret med sociale medieplatforme for optimal præsentation og ydeevne, når indholdet deles på disse netværk.
Når en af disse eksterne tjenester stopper med at svare rettidigt, kan det bringe hele dit website til en brag.
Fanen Eksterne tjenester giver dig mulighed for hurtigt at se, hvilke eksterne tjenester der bruger mest tid. Du kan derefter bruge disse oplysninger til at bestemme, om det er et spørgsmål om hastighed (tjenesten reagerer langsomt) eller mængde (der er for mange opkald til den eksterne kilde) og arbejde for at løse problemet.
Fejl Analytics
Fanen Fejlanalyse rapporterer de PHP-fejl, der er opstået under indlæsning af dit WordPress-sted. Fejlene grupperes i klasser, så du hurtigt kan se, hvor mange forskellige typer fejl der genereres. Fejlene er også bundet tilbage til de faktiske transaktioner, der genererede fejlene. Hvis du vælger en bestemt fejl, kan du også se en fuld stack trace for den transaktion, der genererede fejlen.
Tænk på fejlanalyse som en bedre organiseret PHP error log. Det kan vise sig at være uvurderligt, når man prøver at spore de filer, der genererer PHP-fejl, og de transaktioner, hvor disse fejl opstår.
Fejlfinding af Sider med Langsom Indlæsning
Det mest almindelige problem, som vores team bruger New Relic til at fejlsøge, er tilfældet med en bestemt side eller proces, der tager usædvanligt lang tid at indlæse. Når dette sker, er fanen Transaktioner i New Relic APM næsten helt sikkert det første sted at gå.
Den proces, du skal følge for at diagnosticere en side med langsom indlæsning, er temmelig ligetil:
- Duplicerer den langsomme transaktion.
- Find transaktionen på listen over langsomme transaktioner i New Relic.
- Gennemgå transaktionsoversigten og spore detaljer for at bestemme årsagen til den langsomme ydelse.
Lad os se på et eksempel på dette, og hvordan New Relic kan bruges til at diagnosticere problemet.
Trin 1: Kopier Transaktionen
Lad os se på et eksempel. I dette eksempel ser vores klient langsom indlæsning hver gang et individuelt blogindlæg indlæses. Alle andre sider indlæses normalt, men det tager flere sekunder at indlæse individuelle indlæg.
Så det første trin er at kopiere problemet. I dette tilfælde betyder det, at du besøger et enkelt blogindlæg et par gange for at sikre, at New Relic fanger den nødvendige dato.
Bemærk: Hvis dit website bruger side-cache, som er indbygget i vores platform her på Kinsta, skal du rydde cachen mellem hver sideindlæsning. Ellers vil du ende med at indlæse siden fra cache i stedet for at få WordPress til at generere siden.
Trin 2: Find den Langsomme Transaktion
Når du har duplikeret den langsomme transaktion et par gange, skal du gå til New Relic og vælge fanen Transaktioner. Rul derefter ned, indtil du ser listen over langsomme transaktioner i den nedre højre del af New Relic-dashboardet.
Klik på den transaktion, du debugger for at se detaljer.
Trin 3: Gennemgå Transaktionsoversigt og Sporingsdetaljer
Når du har valgt transaktionen, vises et resume af transaktionen.
Resuméet giver dig mulighed for at se et snapshot-overblik over de komponenter, der har bidraget til transaktionens behandlingstid. I tilfælde af vores eksempelstransaktion er et opkald til en ekstern ressource, www.googleapis.com, ansvarlig for 5.000 millisekunder af en transaktion, der i alt tog 5.350 millisekunder at gennemføre.
Selvom dette er nyttige oplysninger, giver fanen sporoplysninger de detaljer, vi har brug for, for at se nøjagtigt, hvad der sker.
Fanen med sporoplysninger giver et hierarkisk trin-for-trin vandfald, der viser funktionen, databaseforespørgsler og eksterne opkald, som PHP fungerer igennem, når det genererer siden.
I tilfælde af vores eksempelstransaktion afslører sporingsdetaljerne, at et opkald til en Google Analytics-URL er det, der holder processen op. Hvis vi arbejder baglæns fra denne anmodning, initieres det en PHP-funktion kaldet gapp_get_post_pageviews. En hurtig Google-søgning efter den transaktion afslører, at den er en del af Google Analytics Post Pageviews-plugin. Dette plugin er installeret på websiteet og bruges til at tilføje en visningstæller til en sticky header bar.
New Relic har netop gjort det muligt for os at isolere visningstælleren i den sticky header bar som den primære komponent, der bidrager til langsom indlæsning af enkelt blogindlæg på det aktuelle website. Nu ved ejeren af dette website nøjagtigt, hvilken komponent han skal målrette mod at prøve at løse de langsomme indlæsning af individuelle blogindlæg.
Rettelse af Generel Langsomhed
Den næst mest almindelige type problem, vi fejlfinder for vores klienter, er en klage over, at hele websiteet indlæses langsomt. Når hver transaktion tager meget tid at indlæse, sker der sandsynligvis en af tre ting:
- websiteet er sulten efter serverressourcer.
- Et plugin eller det aktive tema skaber problemer.
- websitesdatabasen kæmper for at følge med i antallet af forespørgsler.
Hos Kinsta er problemer med serverressource sjældne, da vores skalerbare virtuelle maskiner er i stand til at styre forskellige mængder belastning. Hvis sitet imidlertid sultes efter CPU eller RAM, kan dette forårsage generel langsomhed, som New Relic ikke fastgør på nogen enkelt ressourcer. Så hvis du ser generelle langsomhed, og New Relic indikerer, at hver del af websiteet bidrager, skal du kontrollere belastningen på din server for at se, om en mangel på serverressourcer er skylden.
Hvis dit website har adgang til masser af serverressourcer, er det næste sted, du vil tjekke for at diagnosticere den samlede langsomhed, omfatte WordPress-plugins og -temaer, fanen Eksterne tjenester og fanen Databaser.
Her er eksempler på generel langsomhed, som kan diagnosticeres ved hjælp af hver af disse faner.
Samlet Langsomhed Forårsaget af et Plugin
Når et plugin forårsager generel langsomhed, vil symptomerne variere afhængigt af den aktivitet, pluginet udfører. I mange tilfælde vil du dog opdage, at en langsom plugin vil påvirke hver side på et WordPress-site. For det sted, hvis data du ser på billedet nedenfor, blev der observeret generel langsomhed på hver forside på siden.
Her er hvad New Relic havde at sige om ydelsen af plugins på websiteet.
Umiddelbart kan du se, at adinjector pluginet bruger mere 15 gange så lang tid som det næste langsomste plugin.
Når du ser data som dette, kan det være fristende at straks afvise plugin som dårligt kodet eller på en eller anden måde ineffektiv. Selvom dette nogle gange er tilfældet, er det ikke altid tilfældet. Fejlkonfiguration af plugin, langsomhed i databasen eller eksterne ressourcer, der er langsomme med at reagere, kan forårsage, at et plugin bruger meget tid.
Så når du ser et plugin, der reagerer langsomt, er det en god ide at tjekke flere andre skærme i New Relic for at finde yderligere oplysninger. Transaktionerne, databaserne og eksterne ressourcerne skal alle kontrolleres, inden de beslutter, at deaktivering af plugin er den bedste eller eneste vej frem.
Samlet Langsomhed Forårsaget af Eksterne Tjenester
Hvis et website er afhængig af et opkald til en ekstern tjeneste for at generere sidevisninger, og at tjenesten holder op med at svare eller tager lang tid at svare, kan resultatet være et WordPress-website, der stopper indlæsningen helt.
Billedet ovenfor er fra det samme site, der producerede skærmbilledet med langsomme plugins ovenfor. Som du kan se, er der en enkelt ekstern tjeneste, der bidrager med et stort beløb til den samlede brugte tid på at vente på eksterne tjenester.
Denne sag viser, hvorfor det er nødvendigt at se information i kombination, før man når frem til en konklusion. Tjenesten, der kaldes i dette tilfælde, er udvikleren af det plugin, der blev identificeret i det sidste trin.
Disse oplysninger tilføjer en vis nuance til situationen. Det er ikke koden for det plugin, der er spørgsmålet så at sige. I stedet ser det ud som om plugin foretager masser af opkald til udviklerens website, og disse opkald, der betragtes som en kombination, bruger meget behandlingstid.
Hvis vi tager tingene et skridt videre og ser på en langsom transaktion for dette website, kan vi se, at dette eksterne opkald ser ud til at kontrollere licensstatus for det aktuelle plugin, hvilket antyder, at licensen til dette særlige plugin muligvis er udløbet .
Under alle omstændigheder kan vi nu rådgive ejeren af dette website om, at adinjector-plugin forårsager den langsomme ydelse, og den langsomme ydelse skyldes gentagne opkald til udviklerens website for at kontrollere status for plugin-licensen.
Samlet Langsomhed Forårsaget af en Overvældet Database
En dårligt optimeret database kan forårsage generel langsomhed på et WordPress-site. En optimering, som vi altid anbefaler, er at konvertere din database fra MyISAM til InnoDB. I New Relic vil denne databaserelaterede langsomhed sandsynligvis vises to steder:
- Først ser du en stor størrelse af MySQL-aktivitet i oversigten.
- For det andet ser du en eller flere databasetabeller, der tager meget tid på fanen databaser.
Start med oversigtsskærmen, et website med en kæmper database ser måske sådan ud:
For at få et bedre greb om, hvilken databasetabel eller forespørgsel der forårsager problemet, skal du gå til fanen databaser.
Fanen databaser viser tabellen og typen af forespørgsel, der tager mest tid. Hvis du vælger en af posterne på listen, kan du se flere detaljer, herunder nogle eksempler på forespørgsler.
I dette tilfælde peger dataene med en finger mod automatisk indlæste data i wp_options-tabellen. Sikker nok bekræfter en hurtig analyse af wp_options-tabellen, at næsten 250 MB data er automatisk indlæst fra denne tabel, hvilket gør dette website til en åbenlys kandidat til vedligeholdelse og optimering af databaser. Tjek vores mere dybdegående indlæg om, hvordan du optimerer din wp_options-tabel og autoloaderede data.
Få nu Fejlfinding!
Når du ved, hvordan du bruger det, kan New Relic være et værdifuldt værktøj til at identificere PHP præstations-flaskehalse på dit WordPress-website. For at få mest muligt ud af New Relic er det vigtigt, at du kender WordPress, forstår de oplysninger, som hver fane rapporterer, og se, hvordan alle oplysninger hænger sammen.
Vi har en interessant interessant casestudie om emnet, og sørg for at tage et kig: Fejlfinding af WordPress-ydeevne – Stuff Happens Tjekliste
Har du nogen nye relikvie WordPress-tip? Vi vil meget gerne høre dem nedenfor i kommentarerne.
Jon er Chief Operating Officer hos Kinsta og er dagligt involveret i Kinstas salgs-, kundeservice- og tekniske supportteam. Jon er en familiefar. Så når han ikke febrilsk trykker på tasterne på sin bærbare computer, hjælper han normalt et af sine børn med at reparere en cykel eller konfigurere Netflix til utålmodige førskolebørn.
Skriv et svar