Etikettarkiv: varnish

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.

Optimera STHLM 2011

I går gick konferensen Optimera STHLM 2011 av stapeln som uppföljning på förra årets lyckade konferens. Även i år så var konferensen lyckad och fokus var mer på säkerhet och prestanda i exempelvis SSL. Årets lokal stod Nalen för.

Dagen började med att Måns och Copylinda hälsade alla välkomna och berättade lite om .SE:s verksamhet som bl.a. omfattar projekt såsom Webbstjärnan och Internetfonden.

Efter introduktionen så pratade Patrik pawal Wallström om vad som gör Internet långsamt då han fokuserade på CDN, DNS samt SSL där Ivan Ristic genomfört en SSL-analys av alla https-sajter i Sverige.

Övriga talare under dagen var Andreas Jonsson från Romab, Per Buer från Varnish, Tobias Järlund  från pappaledighet (Aftonbladet), Michael Sjölin från Guldskeden, Mikael ”Miken” Berggren från Spotify och sist men inte minst så pratade Ragnar Lönn om när biltvätten förstörde hans bil samt Amazon-haveriet.

Video från dagen finns hos Bambuser som SocialVideo vackert stod för.

Bilder (klicka på bild för förstoring):

Serverstrul

Denna vecka så har mer eller mindre alla mina servrar strulat. Jag fick för mig att uppgradera Redis till en lite nyare version som har buggfixar samt äter mindre CPU och passade samtidigt på att uppgardera det PHP bibliotek jag använder för att prata med Redis till owlient/phpredis. Så klart så gick något fel och cachningen i Redis ballade ut och servern dog sakta men säkert pga alla SQL-frågor som ej cachades.

Nästa problem dyker upp på Bloggy då flertalet InnoDB-databasfiler försvinner vid en hastig omstart av servern och MySQL vägrar starta så jag får manuellt använda strace till att lista ut vilken databas som strular och bygga om flertalet tabeller. Då passar jag även på att uppgradera Varnish till senaste versionen och lägger in lite kod för att ej cacha WordPress-adminsidor vilket får till följd att inloggningen på Bloggy misslyckas för alla användare.

Samt så har även den server som sköter bloggsökmotorn Bloggz strulat.. vilket lärdom kan man dra av detta då? Jo, att om du uppgraderar eller ändrar minsta lilla så testa att det verkligen fungerar, lägg till exemeplevis dold HTML-kod som berättar om sidans element verkligen cachas eller ej.

Bildkälla: http://retecool.com/post/computable-awards--fail/1/

Snabb guide till Varnish

Fick en förfrågan från John Angelmo (@veidit) att skriva lite om den supergrymma front-end cachen Varnish. Varnish utvecklas till stor del av företaget Linpro från Norge med hjälp av den danske FreeBSD-utvecklaren Poul-Henning Kamp.

I Sverige är Varnish populärt och används av exempelvis Aftonbladet och SvD. Varnish har en mängd intressanta features och ett mycket kraftfullt konfigurationsspråk som påminner om C.

Använder du Ubuntu som jag gör så är det bara att installera via APT:

$ sudo apt-get install varnish

Standard så lyssnar varnish på TCP port 6081 och skickar vidare förfrågningarna till port 8080 där du förväntas ha din webbserver såsom Apache eller nginx.

Konfigurationsfilen för varnish återhittas i katalogen /etc/varnish/ med filnamnet default.vcl. VCL är också benämningen på det konfigurationsspråk som används som stödjer bla inline C. Se denna PDf-presentation av PHK för mer info.

Det viktiga vi behöver känna till är hur vi pekar ut vårat backend och vilka filer vi vill lagra i cachen. I mitt fall så valde jag Varnish för att Apache drog på tok för mycket minne då exempelvis bara bilder, css och annan statisk information skulle visas.

Nedan konfigurationsfil pekar först ut backend, sedan så sätter den X-Forwarded-For http-headern för att underlägga loggningen i Apache.

Sen så defineras vad som skall chachas.

backend default {
.host = "127.0.0.1";
.port = "8080";
}
sub vcl_recv {
remove req.http.X-Forwarded-For;
set    req.http.X-Forwarded-For = client.ip;
if (req.url ~ "^/css" || req.url ~ "^/images" || req.url ~ "^/facebox" || req.url ~ "^/avatars") {
return(lookup);
}
if (req.request != "GET" && req.request != "HEAD") {
return(pipe);
}
if (req.url ~ "^/feedlist.php" || req.url ~ "^/removefeed.php" || req.url ~ "^/feeds.php" || req.url ~ "^/addfeeds" || req.url ~ "^/42it" || req.url ~ "^/login.php"
|| req.url ~ "^/admin" || req.url ~ "^/settings" || req.url ~ "^/js/tinymce/" ) {
return(pipe);
}
if (req.url ~ "\.(jpg|jpeg|gif|png|tiff|tif|svg|swf|ico|css|vsd|doc|ppt|pps|xls|pdf|mp3|mp4|m4a|ogg|mov|avi|wmv|sxw|zip|gz|bz2|tgz|tar|rar|odc|odb|odf|odg|odi|odp|o
ds|odt|sxc|sxd|sxi|sxw|dmg|torrent|deb|msi|iso|rpm)$") {
return(lookup);
}
}

sub vcl_hash {
set req.hash += req.http.cookie;
}

Uppdatering: Varför jag ibland måste använda Varnish tillsammans med Apache istället för mitt förstahandsval Nginx är pga de invecklade .htacess-filer jag skapat.

Varnishd frontend webcache

I föregående inlägg så skrev jag lite om Varnish webbfrontend proxy. Denna proxy används även av en hel del stora sajter i Sverige. Via Ingvars blogg hittade jag följande lista:

# KIA-Index
Place  20 Varnish running on Sydsvenskan.se (Sydsvenskan.se)
Place  39 Varnish running on hd.se (websvcc.hd.se) (coachen.hd.se) (misc.hd.se) (media.hd.se) (hd.se)
Place  48 Varnish running on alltomstockholm.se (www.alltomstockholm.se) (alltomstockholm.se)
Place  81 Varnish running on nyteknik.se (www.nyteknik.se) (nyteknik.se)
Place  83 Varnish running on affarsvarlden.se (affarsvarlden.se) (www.affarsvarlden.se)
Place  90 Varnish running on nwt.se (nwt.se)
Place  99 Varnish running on bt.se (www.bt.se)
Place 102 Varnish running on smp.se (www.smp.se) (smp.se)
Place 112 Varnish running on barometern.se (www.barometern.se) (barometern.se)
Place 113 Varnish running on norran.se (vader.norran.se) (norran.se)
Place 130 Varnish running on blt.se (www.blt.se) (blt.se)
Place 245 Varnish running on pchemma.se (pchemma.se) (www.pchemma.se)
Place 250 Varnish running on ut.se (ut.se) (www.ut.se)

# Swedish Netcraft toolbar users
Place   6 Varnish running on www.aftonbladet.se (www.aftonbladet.se)
Place  24 Varnish running on www.svd.se (www.svd.se)
Place  29 Varnish running on torrents.thepiratebay.org (torrents.thepiratebay.org)
Place  38 Varnish running on aftonbladet.se (aftonbladet.se) (www.aftonbladet.se)
Place  44 Varnish running on www.e24.se (www.e24.se)

Bloggys infrastruktur

Tänkte beskriva lite om hur Bloggy är uppbyggt rent tekniskt. En förfrågan till Bloggy går ungefär igenom följande lager:

MySQL <- Sphinx <- Memcached <- Apache <- Varnishd

Varnish är en högpresterande webb frontend-proxy utvecklat av ett norskt företag och används  exempelvis av Aftonbladet. Detta går att utläsa genom HTTP-headern X-Varnish.

Denna frontend-cache används för att hantera alla statiska filer såsom CSS och bilder. Apache behöver jag inte skriva så mycket om men sedan kommer en intressant del och det är memcached som är utvecklat av Facebook.

De flesta SQL-frågor går genom memcached för att cachas ett antal sekunder, varje SQL-fråga är noggrant studerad hur länge den behöver cachas.

Sphinx är också en intressant del eftersom den gör att fulltextsökningar mot olika tabeller i MySQL-databasen. Sphinx tar hand om runt 40 sökningar i sekunden.

Sedan så kommer MySQL som hanterar allt annat som inte fångas upp av något av ovanstående system. Alla frågor har optimerats så att filsorteringar (file sort) och dylikt används minimalt. Jag har även tidigare (2007) bloggat om hur du kan optimera din MySQL databas.