WordPress prestanda 101

Under Sweden Social Web Camp så försökte jag på kort under en session tid förklara hur man kan analysera och hitta flaskhalsar i WordPress gällande prestanda. Så därför försökte jag här sammanfatta det jag pratade om på några rader.

Först och främst så bör du stänga av alla plugins och då se om prestandan fortfarande är dålig, för tyvärr finns det många dåliga plugins (se här då Computer Sweden intervjuade mig och Nikke, år 2009).

Okej, nästa grej att testa är att slå på något cache-plugin i form av W3 Total Cache eller WP Super Cache. Du kan även testa att ”städa upp” i databasen då många plugins lägger temporär eller onödig information i databasen (kommentera om du vet något plugin som gör detta).

Använder du ett cache-plugin så bör du även installera memcached samt titta i källkoden längst ner på sidan hur många SQL-anrop som cachas, exempelvis (skriver WP Super Cache också ut detta?):

Object Caching 730/765 objects using memcached

En annan grej man kan testa är att använda strace direkt från kommandotolken i Linux tillsammans med PHP, ungefär så här:

$ cd /min/blogg/

$ strace php index.php

Så får du lite loggrader utspottade på skärmen och om det står still länge på ett ställe så ser du exakt vad som händer på den raden. Samt så bör du även testa Xdebug så kan berätta exakt vilken rad i PHP-koden som går långsamt, tar lite tid att installera och använda.

Du kan även titta i MySQL:s slow-log som kan aktiveras på eller hittas i /etc/mysql/my.cnf (sök efter log_slow_queries).

Sist men inte minst det som jag brukar göra är att lägga upp Varnish som en front-end proxy framför Apache exempelvis, detta är en helt mer eller mindre transparent lösning. Kom även ihåg att Apache slukar massor av minne jämfört med Nginx som istället kan användas till memcached. Detta är nog det bästa tipset jag kan ge samt att testa använda ett CDN.

Sen finns det så klart mycket man kan göra på själva sidorna som WordPress spottar ut (sprites, javascript etc), men det är utanför detta blogginlägg.

Uppdatering: Glömde skriva två saker som jag nämnde på sessionen, dels är det att använda sig av en OP-code cache typ APC eller eAccelerator samt så kan även URL-strukturen i WordPress slöa ner prestandan.

3 reaktioner på ”WordPress prestanda 101

  1. Tack för infon. Senare delen av inlägget är för avancerat för mig, men jag försöker samtidigt skapa reda i vad det är som slöar ner bisonblog.se så mycket, speciellt när man surfar via mobilen. Har stängt av alla plugins utom wp cache (som jag även slagit på och av tidigare för att kolla eventuell skillnad), men det verkar inte hända så mycket. OBS, det här är inte en support-hjälp-fråga till dig utan snarare ett utrop i desperation. Jag VET ju att det finns massor att göra och optimera, men jag saknar helt enkelt skillsen för de mer server-relaterade grejerna (saker som inte går att göra direkt från wp-gränssnittet).

  2. Intressant information Jonas!

    Jag höll på i April med att optimera WordPress Network (MU) med ca 60 000 bloggar. Det är två stora problem med WordPress och du tar upp det ena som är relevant med en enkelinstallation och speciellt om man ligger på ett gemensamt webbhotell med andra, men det andra stora problemet uppstår med Network/Multi User och flera bloggar.

    Det problemet är nämligen att WordPress har ca 10 tabeller per blogg och MyISAM som är standard i WP behöver två filer per tabell vilket gör att varje blogg behöver ca 20 öppna filer. Summera ihop det med att MySQL lägger alla MyISAM filer i samma bibliotek dvs i mitt fall drygt 1 miljon filer.

    Vad jag kom fram till var denna lösning på 1 server:

    – Använda InnoDB med patch för att minska tabellminnet som minskar på belastningen av filsystemet/OS med att öppna/stänga många filer.

    – Använder Nginx som front-end cache proxy till Apache

    – PHP accellerator

    – RAID 10

    – Ingen plugin Cache (WP Cache och även Total Cache ökar ”load” för mig oavsett om jag aktiverade cache med mod_rewrite)

    Jag har då provat alla möjliga kombinationer och ovan var det bästa med WordPress för mig under Ubuntu, alla andra varianter med Plugin Cache, Varnish, Nginx, Apache genererade mer systemkraft att det inte blev praktiskt i slutänden. Ovan lösning fungerar bra på sådär ungefär 250 000 bloggar, men sedan måste man dela upp det i shards och det finns några etablerade lösningar som bl.a. WordPress.com använder.

  3. Just nginx, PHP5-FPM (med APC), Varnish och memcached fick en väldigt välbesökt blogg som rullade på en standard LAMP-stack att gå från 10+ sek långa laddningstider till under sekunden.

    I/O wait sjönk från ruskigt tråkiga 70% til 0.01% och mängden reserverad RAM sjönk från konstanta 2 GB (dvs allt minne på VPS:en) till 1.3 GB – och då består runt 90% av minnet av ren cache.

    Dock tror jag det finns hopp för Apache. Bland annat event MPM:n ser ut att rätta till prestanda/minne ration. Och låter man Varnish serva allt statiskt material och dedikerar Apache till att ha hand om PHP5-FPM eller vilket språk man nu använder så kan man få både god prestanda och vettig resursförbrukning.

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *