Prestanda som data point

[Beckzar]

Har snöat in på performance de senaste dagarna och bl.a. läst Jims artikel om Wordpress och Reddit (http://www.jimwestergren.com/wordpre...rontend-cache/) Intressant läsning. Hade varit kul att ta en diskussion om era erfarenheter om hur viktig performance är som data point för ranking. Själv kör jag med dedikerade servrar/VPS:er på våra viktigaste sajter, men det finns säkert en hel del till att göra med caching osv men det känns svårt att få det bra med sidor som ofta jobbar med dynamisk data osv.

Hur är era erfarenheter?

[Tobias Nyholm]

Kul, performance är ett intressant område. Men jag är dock inte så överdrivet imponerad av Jims lösning. Till exempel så läcker den minne som ett såll. Minne är dyrt, men det är å andra sidan konsulter också...
Om man analyserar vad som verkligen tar tid när man hämtar startsidan för en wordpress blogg, då är det oftast överföringen av media som tar längst tid. PHP scriten körs på nån tiondelssekund och databasanropen på några hundradelarssekunder.

Det finns såklart klantiga programmerare som skriver kod som exekverar mycket långsammare. Antingen så kan man inte bättre eller så resonerar man att laddtider spelar mindre roll.

För att optimera överföringen av media kan man se till att man cachar innehållet både på servern och klienten. Man kan komprimera innehållet. Se till att request headers blir mindre. Man kan använda image sprites. Man ser till att sprida ut bilder på olika domäner.

Vill man cacha sitt innehåll hårt så ska man inte göra det med PHP. Det är fel lager. Man ska använda program som Varnish eller Valgrind.

Kort sagt så finns det alltid saker man kan göra så att det blir bättre. Frågan är bara hur mycket tid man vill lägga ner på en förbättring som knappast märks.

[Beckzar]

Vilken komponent av den lösningen Jim föreslår läcker minne? Varnish verkar intressant, hur är stödet för att programmatiskt "tömma cachen" via PHP (t.ex. via en custom plugin) då man t.ex. får in ny post eller importerat ny extern data till WP?

Edit: läste lite mer om Varnish, verkar grym och all styrning sker via HTTP. Ska definitivt testa.

[Tobias Nyholm]

Du tömmer inte cachen. Det där sköts automatiskt. Du installerar, gör inställningar och sen glömmer.

Jag vill inte såga Jim. Hans lösning får en guldstjärna i kreativitet.

Redis är som sagt en nosql databas som sparar allt i minnet. Inget skrivs till disk (i tidigare versioner skrevs delar av databasen till disk, men inte längre). För varje nytt request sparas ett par kB i databasen med HTML. Detta levereras sedan till nästa besökare blixtsnabbt. Detta innebär att du för alltid sparar mer och mer data. Du vill inte spara en sida som aldrig används i primärminnet. Det är emot grundläggande datorarkitektur...

Om till exempel du har en webbplats med 100 000 webbsidor som vardera har html för 50kB. Detta innebär att du har 0.5 Gb för att hålla din databas igång. Vilket jag kan tycka är slöseri med dyra resurser.

Om jag har granskat lösningen korrekt så stödjer den heller inte följande PHP kod:

echo date('l); //prints the day of the week  

Detta kommer alltid visa "torsdag" eftersom det var idag som vi visade sidan första gången och det är då vi cachar resultatet.


Nog är jag petig i min kritik. Cachning med Redis som Jim presenterar kan vara ett bra och enkelt sätt för att snabbt leverera statiskt innehåll (som går att ändra dynamiskt men ej kan ändra sig själv) till små och medelstora webbplatser om man inte har något emot att köpa lite extra minne.

[Beckzar]

Fast i vissa fall vill du kunna "purga" objekt t.ex. för en sportsbettingsajt jag kör, där vi importerar odds för olika matcher typ en gång vart 10 min. Men detta kan man tydligen göra enkelt med en HTTP PURGE request: https://www.varnish-cache.org/docs/t...e/purging.html

[Jim Westergren]

Hej Tobias,

Varje URL cachas bara en gång tills det att den tas bort med F5 eller liknande. Om man har något dynamiskt som måste ändras hela tiden så rekommenderar jag en str_replace på $html i cache.

Jag tippar på att min cache lösning använder mindre än halva storleken på MySQL-databasen. Nästan försumbart, kanske 50MB för min del. Att en blogg skulle ha 100 000 sidor är inte helt realistiskt men då skulle man kunna ha typ header och footer osv som enskilda objekt. Man kan även sätta expire på cachen. Jag hade det innan.

Givetvis ska man optimera på klientsidan med, gzip, CDN osv.

[Tobias Nyholm]

Jag tror absolut att din lösning fungerar för många av våra typer av webbplatser. Som sagt:

Nog är jag petig i min kritik. Cachning med Redis som Jim presenterar kan vara ett bra och enkelt sätt för att snabbt leverera statiskt innehåll (som går att ändra dynamiskt men ej kan ändra sig själv) till små och medelstora webbplatser om man inte har något emot att köpa lite extra minne.

Angående 100 000 sidor... Jag menar självklart 100 000 olika URLer. Säg till exempel söksidan i WP. Urler som:

www.domain.se/?s=term
www.domain.se/?s=other
www.domain.se/?s=kittens

Dessa cachas som olika sidor. Du får dessutom problem när du skriver ett nytt inlägg om kattungar. Det nya inlägget kommer inte dyka upp i sökningar.

Det är klart att man kan skriva regler för att lösa dessa problem:

• Att vissa URLer aldrig ska cachas.
• Redis har en "remove by age"-policy som man kan ställa in.
• Man kan själv hålla reda på nycklar i cachen som man plockar bort om dem inte används osv.

Jag säger att man borde tänka igenom vad som verkligen cachas, hur länge och när cachen uppdateras. Det är en approach som har en annorlunda arkitektur. I det generella fallet skulle jag inte gå på denna lösning.

[Beckzar]

Ja, eller så skriver du en plugin som "purgar" cachen vid postningar, import av extern data osv.

Dessa cachas som olika sidor. Du får dessutom problem när du skriver ett nytt inlägg om kattungar. Det nya inlägget kommer inte dyka upp i sökningar.

Det är klart att man kan skriva regler för att lösa dessa problem:

• Att vissa URLer aldrig ska cachas.
• Redis har en "remove by age"-policy som man kan ställa in.
• Man kan själv hålla reda på nycklar i cachen som man plockar bort om dem inte används osv.

Jag säger att man borde tänka igenom vad som verkligen cachas, hur länge och när cachen uppdateras. Det är en approach som har en annorlunda arkitektur. I det generella fallet skulle jag inte gå på denna lösning.

[Jim Westergren]

Gällande URL:er för sökresultat:

Ändra rad 114 från:

if (!is_404()) {  

Till:

if (!is_404() && !is_search()) {  

Jag har uppdaterat koden på Github. Tack Tobias.