Öppna upp flaskhalsarna med Tideways-integrationen

Publicerad: 7.5.2018 Uppdaterad: 6.11.2018

Tideways är en tjänst med vars hjälp det är enkelt att utforska och följa PHP-kodens prestanda, eller att hitta just den rad i koden som förorsakar problem på din WordPress-webbplats. Vi är stolta över att kunna berätta att vi nyligen integrerat Tideways i våra tjänster.

Ett liknande redskap, XDebug, har vi redan haft i bruk en längre tid, dock enbart för utvecklingsmiljön. Det bästa med Tideways är att lösningen är enkel att använda även i produktionsmiljön. I vår integration plockar vi automatiskt upp ett enprocents stickprov av er webbtrafik. Detta innebär att effekten på webbplatsens prestanda är påtagligt mindre i jämförelse med till exempel XDebug.

Tideways är tillgängligt för alla våra kunder. Vi tar inte ut några användaravgifter, men för att kunna använda tjänsten måste du betala Tideways för din önskade servicenivå. Riktlinjer för införandet av Tideways finns i vår utvecklardokumentation. När du har aktiverat tjänsten (glöm inte att PHP måste ha version 7.2!), kan du sätta dig ner och beundra all data som rinner genom Tideways instrumentpanel.

Hur hittar man flaskhalsen?

Vår kund Rekki.fi märkte för en tid sedan att laddningen av deras WooCommerce-produktsidor tog längre tid än normalt. Problemet kunde verifieras med hjälp av ett annat verktyg som levereras av Seravo, den månatliga Go Access-rapporten som finns under Tools > Reports på WP Admin. Det var också lätt att hitta problemet när produktsidorna granskades med kommandona wp-speed-test och wp-load-test.

Tideways studerar hela webbplatsens funktion och lyfter automatiskt fram de webbplatser som laddas långsamt, men om exempelvis prestandan på en viss webbplats verkar underlg, är det möjligt att manuellt lyfta fram den för specialgranskning.

På Tideways instrumentpanel finns sektionen My Callgraph Traces där man med Trigger Trace enkelt får fram de parametrar som behövs för att starta kontrollerna. Kopiera strängen som skapats för ändamålet under rubriken GET-Parameters och klistra in den i din webbläsare efter den webbadress du vill granska. Några sekunder efter laddningen av webbsidan visas sidan på Tideways-kontrollen.

Tideways trigger trace view

Standardvyn för kontrollen är en interaktiv vattenfallsvy. Du kan klicka på vilket element som helst i vyn för att få fram mer detaljerad information i sidopanelen. Vattenfallsvyn illustrerar det som sker under hämtningen. Även om sidan du granskar inte är den egentliga flaskhalsen, kan du ändå med hjälp av vyn få en inblick i vad all din kod gör på webbplatsen.

I det här exemplet märkte vi att det i slutet av laddningen gick en halv sekund medan tillägget Facebook for WooCommerce hämtade ett stort antal artiklar ur databasen, en funktion som sannolikt kan betraktas som onödig.

Alla funktionskommandon som körs vid laddningen av webbsidan har presenterats i tabellen under fliken Calls och är sorterade efter hur mycket tid de olika funktionerna använde. Den här vyn är säkert bekant för alla som använt XDebug. När man klickar på funktionsnamnet öppnas tilläggsinformation i sidopanelen, med vars hjälp man kan lokalisera det kodavsnitt som var orsak till tidsslöseriet och måste rättas.

Med hjälp av vyn kunde vi dra slutsatsen att det långsammaste databaskommandot utfördes i funktionen inject_view_category_event. När funktionen väl identifieras, behövde man bara hitta koden som behövde rättas. Tideways har ingen direkt koppling mot kodbasen, som till exempel XDebug har. Vi var alltså tvungna att öppna en SSH-session, och med kommandot grep leta fram var i koden funktionskommandot finns.

I det här exempelfallet hittade vi lätt filen och radnumret där funktionen inject_view_category_event först definieras. För att sedan lösa problemet behövde vi bara skriva om en liten kodsnutt.

Reparationen är lätt när man vet var buggen ligger

Vi insåg att den ”slöa” funktionen vi hittat körde kommandot $wp_query->;get_posts() vid varje sidoladdning. Den hämtade alltså varenda gång alla artiklar från databasen, i detta fall alla produktsidor som fanns listade. Vi ändrade till kommandot wp_query->;posts så att de produktsidor som hade redan hämtats vid tidigare laddningar i stället kunde plockas fram direkt ur minnet.

Det var enkelt att verifiera förändringen genom att granska ett nytt stickprov från samma webbsida, där den långa röda linjen som representerade det tidigare, tyngre och långsammare SQL-kommandot försvunnit och totaltiden för woocommerce_after_shop_loop hade minskat från en sekund till 160 millisekunder.

I vårt exempelfall kan det finnas kvar fler lämpliga optimeringar, men problemen måste lösas ett i taget. Eftersom WordPress är licensierat under GPL och de flesta av dess tillägg utvecklas som öppen källkod, lönar det sig absolut att sända tillbaka rättningarna till det ursprungliga projektet. På så sätt behöver man inte för all framtid hålla ordning på de rättelser man själv utforskat och infört. I stället blir de sannolikt inkluderade i de kommande uppdateringar av tilläggen. I detta fall sände vi vår förbättring till Facebook genom Github.

Kommentera

Otto Kekäläinen

Verkställande direktör otto@seravo.se @ottokekalainen

Sök Seravo.se

Mer läsning

Introduktion till datasäkerhet med WordPress

29.10.2018

Det finns gott om myter och välmenande råd ute på nätet angående datasäkerhet med WordPress. Det vanligaste tipset verkar vara […]

Gutenberg förvandlar WordPress

23.10.2018

När versionen 5.0 av WordPress kommer ut, får vi lära känna en nyhet som har rört upp stora känslor inom […]