[totoo]

Jag arbetar ju med ett community och har mycket tid att lägga på att få ned driftskostnaderna så mycket som det går, samtidigt som jag gör så mycket jag kan för att användarna också ska få en snabb site med bra responstid.
Siten jag bygger ska vara väl anpassad för att ha 2 miljoner användare och 100.000 parallellt inloggade medlemmar.
OBS: Om det finns sannolikhet att det lyckas eller ej hör inte hit - men jag tänker inte sätta ribban för lågt så att det blir onödiga ombyggnationer.

Nu kommer jag resonera kring nivåer som kan anses vara helt försumbara, men "många bäckar små", samt att även microsekunder kan ha stor inverkan om uppdateringsfrekvensen är tillräckligt hög.

Detta meddelande riktar sig egentligen främst för dem som har kodat stora webbplatser som gärna har 50k+ besökare om dagen, eller till personer som helt enkelt är väldigt pålästa.

Tyvärr är jag relativt grön på de djupare områdena på webbfronten. Jag kodar riktigt bra php och har väl vanligtvis försvarbara mysqlfrågor, även om jag ibland är lite tvivelaktig där, men det finns saker jag inte riktigt har svaren på.

JS och Ajax
Jag använder mycket js och ajax för att ge användaren bra respons på aktiviteter. Vi vet ju att en js-operation är snabb som ögat, så en undermeny baserat på js ger ju användaren en känsla av effektivitet.
En del sidladdningar gör jag också via ajax, t.ex. om jag har ett gäng flikar. Laddningstiden blir enormt snabb då det t.ex. bara är 5k istället för 30k som ska laddas, samt att det bara blir en enda request, istället för flera då inte script, stilmallar och bilder etc blandas in i onödan (alltså, det som inte behöver laddas om laddas inte om).

Cacha phpgenererad kod
Jag cachar också mycket phpgenererad kod. En lista på senast inloggade personer består av en textfil med htmlkod som genereras varje gång någon loggar in. Samma sak görs med forumsmeddelanden och allt annat som visas ofta, visas lika för alla men inte förändras speciellt ofta.
Detta ger också ett stort lyft i prestandan då antalet mysqlfrågor och phpexekveringar genereras.
Här vet jag dock att det går att ta steget längre - det finns mer effektiva sätt att cacha, typ cacheservrar, delat minne i php och lite sånt som jag inte förstår mig på än - någon får gärna dela med sig av erfarenheter.

Minimera data vid sidladdning
Förut har jag också använt mig av verktyget på websiteoptimization.com som dumpar ut lite information om vad den tycker om min site. I början när jag tog fram mitt ramverk så brydde jag mig för mycket i vad det där verktyget och gjorde allt för att det skulle rapportera en så liten total sitestorlek som möjligt.

Jag använde två huvudsakliga metoder för att få ned storleken som den rapporterade.
Verkyget rapporterar storleken på sitens första sida (om man inte anger annat), och jag resonerade såhär enligt god utvecklaranda "Startsidan ska inte kräva onödigt mycket bandbredd, för om man har kass uppkoppling så kan man väl i alla fall få reda på vad det är för typ av site innan modemet har brunnit upp. På sida två däremot, då kan man kräva lite mer".

I dagsläget använder jag 14 javascriptfiler (117k) och 32 stilmallsfiler (146k) för communityt. Bortsett från ordning och struktur så är argumentet helt enkelt att t.ex. stilmallar som bara behövs i forumet bara ska behöva laddas om man visar forumet.

Jämfört med att ha alla stilmallar liggande i samma fil så ger jag användaren en chans att slippa ta emot ett gäng kilobyte för html som han kanske aldrig kommer att se.
Vi kan i alla fall konstatera att det är en viss optimering, dock ganska liten pga att det hela cachas hos mottageren, men den ger mig också bra möjlighet till struktur.

MEN, http-requests?
Sedan läste jag en optimeringsartikel som var lite smått tvivelaktig enligt mig där det stod att man ska arbeta för att minimera sina http-requests. Detta kan ju anses som modell självklart, men vad är smartast ur trafikperspektiv? Ska man klämma ihop allt till typ en fil eller dela upp i flera?

Utför browsern överhuvudtaget dessa requester när filen är cachad? Jag vet att den cachas om ibland, typ vid browsersessionens första besök (alltså första besöket sedan browsen startade) samt några andra intervall - men om browsern totalt ignorerar dessa reqests när filen är cachad så lär ju inte detta spela någon roll. Eller gör den en request ändå och typ kontrollerar filstorleken (för att veta om det ska cachas om) eller något? Jag förstår att olika browsers gör på olika sätt, men vad har ni för erfarenheter?

Jag kan ju sitta och mäta min nätverkstrafik, men den delen av verksamheten är egentligen inte min starka sida, eller ligger i mitt intresse, jag får lära mig det där med tiden. Fast folks erfarenheter är just nu mer värda än mina halvdana tester.


Browsers cachar html-filer?!
Kan jag påverka min data så att browsern behåller även htmlfiler? Jag vet att sådana kan cachas på ett eller annat sätt, men om jag då och då genererar ut hela htmlfiler istället för att ha php-filer, minskar jag trafikmängden då?


Communityn använder nästan alltid frames
Om vi tittar på de flesta communityn vi känner till så är de nästan alltid uppbyggda med frames.
Alla svenska communityn jag vet (räkna bort rena form etc) använder frames i sin struktur. De flesta av oss är lärda att tycka illa om frames i 99 fall av 100, men faktum är ju att de har sina goda sidor.

Jag har några "besvär" som frames skulle lösa, samtidigt som de skulle medföra andra nackdelar.

Några saker som gör att jag väldigt gärna skulle använda frames:

1: Mindre total trafik då man bara uppdaterar contentramen och kan behålla all info i ramarna runtomkring (som i 9 fall av 10 inte behöver uppdateras)

2: (mycket text)

I dagsläget presenterar mitt community användarspecifik information på skärmen hela tiden. Man ser sitt namn + lite poäng och statusar etc. Fördelen med det är översikten är god, nackdelen är att det hela blir svårare att cacha (informationen blir mer dynamisk). Många siter väljer ju att inte presentera någon användarspecifik information i onödan alls just pga att man försöker göra innehållet statiskt och cacha det. Detta är ju t.ex. vanligt även på forum, att trådarna ser lika ut för alla, och att alla har knappen "radera inlägg" fast alla inte har rättigheterna. Sedan när man klickar så kontrolleras rättigheterna = optimering eftersom folk inte klickar "radera inlägg" speciellt ofta.

Dit jag vill komma:
Designen ifråga är av trekolumnsmodell + sidhuvud. Fyra stora fält totalt varav normalt bara ett behöver uppdateras.
Eftersom frames bygger på separata htmlfiler för varje ruta så kan jag alltså cacha hela htmlfiler och inte bara delar av dem.

Jämför med idag om jag vill cacha forumsvyn. Då måste jag cacha enbart contentfältet då mina tre andra stora fält är användaspecifika, så de kan ju aldrig cachas. Så när sidan ska skickas till användaren så måste jag mha php rendera sidhuvudet, vänsterkolumnen, rendera cachad content, rendera högerkolumnen.

Modellen med frames hade bara behövt hämta min cachade content.
I stort sett så kan jag cacha samma mängd data, men jag kan hantera det på olika bra sätt då jag inte behöver blanda in php för att skicka rätt data, utan om någon begär content så kan jag skicka endast content, istället för att pussla ihop en massa olika fält som det blir annars.

Jag vågar spontant påstå att frames ger mig stora optimeringsmöjligheter, nackdelen är väl något sämre navigation, samt att sökmotorerna inte är vidare smidiga hos mig längre, och sökmotorerna är väldigt viktiga för oss.

Till följd av att använda frames och att en mindre yta renderas om så:

1: Färre queries behöver utföras då mindre jobb utförs
2: Mindre phpexekvering (marginellt dock)
3: Mindre trafik ut från servern
4: Mindre trafik till användaren = snabbare navigation.

Jag befarar spontant att frames kan vara den absolut bästa optimeringsmöjligheten jag har kvar, och det skär i mitt hjärta att överhuvudtaget överväga tanken att byta ut modellen till att använda frames.


Slutsats, nä, finns ingen

Är det någon som har orkat läsa långt nog för att resonera lite med mig? Alla relevanta erfarenheter och kunskaper är av värde.


Stort tack!
MVH Tobbe, Falun