Skala WordPress – fixa databasen

En vanligt fråga är om det ens är möjligt att bygga en webbplats i Aftonbladets storlek i WordPress. När den dyker upp känns det bra att peka på WordPress.com. Med dess 25 miljoner bloggar och en halv miljard dagliga sidvisningar kan den väl ses som en kapabel installation. Att 400.000 inlägg och lika många kommentarer postas varje dag visar ju även att det är ett CMS som pallar med konstanta inserts.

Men varför finns det då en myt om att WordPress skalar dåligt?

Ett misstag som många gör är att utgå från en egenhostad standardinstallation med slumpvis valda plugins från WordPress rika pluginkatalog. En installation som inte är förberedd för hög last och som dessutom använder sig av tilläggskod som lika gärna kan vara skriven av en glad amatör som en ingenjör kommer naturligtvis att stå pall särskilt länge för en stor besöksvolym.

Som standard skeppas WordPress förberedd för en LAMP-installation på ett vanligt webhotell – målet är det ska vara väldigt låg tröskel för nyfikna. Den berömda 5-minutersinstallationen är en nycklarna till WordPress enorma framgång.

Så, vad kan den med ambitioner göra för att nå framgång med en större installation? Förutom hygienfaktorer som snabba diskar, kraftiga processorer och feta linor finns det mycket att göra. LAMP i CGI-läge är smidigt och välbekant för många – men har oftast för mycket overhead. Automattic själva kör med proprietära Litespeed, som inte bara är ruggigt snabbt utan även är kompatibelt med en mängd Apachemoduler. Jag väljer ofta en lösning med Nginx och fastcgi. För den som enkelt och snabbt vill prova något nytt rekommenderas LowendVPS’ fantastiska bootstrapping-script – med några kommandon får du en komplett NAMP-miljö uppconfad för WordPress.

Även i WordPress-stacken finns mycket att göra:

Ett vanligt prestandaproblem beror på allt för dynamiska permalänkar:  /%postname%/ som permalänkmall må vara snyggt och piffigt men innebär också onödigt hög belastning i vid var anrop eftersom wp först måste lista ut vad sidan innehåller för att kunna servera rätt sorts innehåll. Använd till exempel /artikel/ som bas för tidningsartiklar (eller varför inte klassikern /%year%/%monthnum%/%day%/%postname%/ ?).

Eftersom WordPress API är väldigt tillåtande är det även möjligt att snabbt slänga ihop ett tema eller plugin och sedan sprida det vidare till världen. Hastighetsoptimering eller certifieringar är inget krav för att publicera sina alster i de officella tema- och pluginkatalogerna.

Plocka fram dina pluggar och teman. Kavla upp ärmarna:

  • Se till att alla plugins gör eventuella SQL-anrop genom $wpdb-objektet – egnabryggda lösningar med mysql_connect() är inte bara onödigt, det förhindrar caching och lastfördelning.
  • Se till att alla frågor som inte måste vara realtids-fräsha cachas via WP_Object_cache eller Transients API:et (du vill antagligen använda det senare eftersom det garanterar att data sparas och faller tillbaka till mysql-lagring om andra möjligheter saknas).
  • Installera memcached på så många maskiner som möjligt och kicka igång Memcached Object Cache som ser till att WordPress objectcache använder snabbt ram i stället för dyra dbfrågor.
  • Välj ut en cache-plugin som lirar bra med dina databasfrågor. En favorit på senare tid är  DB Cache Reloaded Fix  som inte bloatad med system för sidcachning (som jag ändå inte använder).
När grundjobbet är avklarat är det dags att förbereda installationen för en större mängd frågor. Det först är att byta ut standardklassen för databasfrågor mot HyperDB – ett databasmodul på steroider utvecklad för WordPress.com. Med stöd för replikering och partitionering är det är nu möjligt att klustra upp installationen ordentligt och fördela sqlfrågorna över en mängd servrar.
Nästa steg är att se dynamiska sidor och frontend-cachar, men det är en bloggpost för sig.
Annonser

4 thoughts on “Skala WordPress – fixa databasen

  1. Intressant och stort tack för denna blog, kul på alla sätt!

    Jag har en fråga, undrar bara om ni har erfarenhet av att köra WP som ramverk? Dvs, använda backend för hantering av användare och att enkelt bygga flöden och hantera data, och sedan bygga något helt annat i fronten?

    Tack //

  2. Vi kopplade idag ihop WordPress med förstasidesredigeringsverktyget (långt namn…) Dr Front från Aptoma och det fungerade riktigt bra. För nyhetssajter är det viktigt att förstasidan snabbt, enkelt och flexibelt kan uppdateras och där har inte WP nått hela vägen. Bloggpost kommer snart.

  3. Jag optimerar ibland WP då man stöter på problem, att bara slänga på Varnish framför löser många problem och huvudvärk. Så klart så blir det problem också eftersom man inte vill cacha för mycket

    • Varnish är fantastiskt bra och räddar det mesta men det är ändå viktigt att inte dölja underliggande prestandaproblem så långt fram. För eller senare blir det trubbel om inte hela kedjan är optimerad.

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s