[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

[eg0master]

För det första så finns det ett talesätt: "Premature optimization is the root of all evil"
Det är så gott som alltid slöseri med tid och resurser att optimera något för att man "tror" att det behöver optimeras. Dock har du ju läst på en hel del och jag kan nog bidraga med några tankar kring antalet HTTP requests.

Många HTTP requests är främst ett problem om man har en lina med långa latenser (typ GPRS, 3G osv). Och då främst i kombination med HTTP/1.0 och tidigare då endast en request görs per TCP connection eftersom det tar ganska lång tid att sätta upp en TCP förbindelse. Nu använder ju alla större browsar HTTP/1.1 som återanvänder connections vilket minskar fördröjningen vid flera requests till sama host.
Tester jag utförde för ett par år sedan (och jag tvivlar på att senaste IE och Firefox i någon större utsträckning förändrat detta) visade att IE använder sig av max fyra (4) samtidigt öppna connections. Så när du laddar en sida (låt oss anta att hälften av javascript och hälften av stilmallarna behövs) så behövs 24 requests (1 (sidan)+7 js+16 css) + alla eventuella bilder. Helt utan bilder måste alltså (med en jämn fördelning) 6 requests köas i varje öppen connection (givet att personen inte har flera fönster i browsern öppna som surfar på andra hostar).
Dock kommer ju inte allt data skickas eftersom servern normalt kommer svara med en 304 - Not Modified, men min erfarenhet är att browsern iaf frågar servern om varje fil även om den är cachad lokalt för att se att den inte förändrats. Och innan den fått sitt 304 svar kan den inte fortsätta.

Så ja, det finns ett potentiellt problem med så många filer - men bara om väldigt många av dem används på samma sida. Dock i linje med det jag skrev först skall du inte optimera detta om du inte med tester kan visa att detta är ett problem.

[bassman]

Nu är jag ingen php-guru men jag har vänner som är det.
Med utgångspunkt från vad de säger rekommenderar jag att använda och lära sig Zends produkter grundligt, kanske till och med ta deras kurs och bli en "Zend Certified Engineer". Det är nog värt det enbart för caching-kunskaperna om inte annat.

[danjel]

Tänk på att det du talar om är prestanda men det har ju inget att göra med skalbarheten, vilket är det primära att fokusera på när det gäller så stora datamängder och trafik. Tex att inte använda native php sessions eftersom då försvåras lastbalansering..är det något du tänkt på eller är det "utanför" denna tråd?

[totoo]

tack för svar.
danjel, ehm... det finns inget av värde som är utanför denna tråd tror jag.
Berätta gärna mer.

[danjel]

Browsers cachar html-filer?!

Ja det går ju att cacha på klientsidan

header("Cache-Control: ......")

vilket minskar trafikmängden, dock så kan det nog
vara lite svårt att få det att lira korrekt i olika webbläsare/proxys m.m har jag hört
men har inte testat själv..



Vad gäller frames skulle jag inte säga att behöver
lägga in det av anledningen att klara bra prestanda,
det är ju inte mycket extra html som skickas om det är schysst gjort med css
samt att mycket annat går att lösa med tex ajax, dvs ladda "livemess" m.m
Och om du cachar databasförfrågningar som görs på varje sida så vinner du en del.
Samt en observation jag gjort är att många laddar om hela framesetet vid in och utloggning, en ganska stor del av användarna loggar ju ofta bara in för att se om de fått ett nytt meddelande eller liknande och loggar sen ut..Då har man betydligt fler requests än vid en vanlig icke framad site,
så jag tror inte man vinner så mycket generellt på frames vad gäller requests och bandbredd och prestanda

[grazzy]

Browser-cachning är främst intressant för statiska objekt (bilder, css, js etc). HTML är ofta dynamiskt och cachas bäst serverside för att klippa cpu-tid (parsning & databas). Slå på mod_gzip/deflate för att spara bandbredden (men öka responstiden oftast).

Misstänker tyvärr att det här inte var några nyheter för trådskaparen..

[danjel]

Originally posted by totoo@Dec 15 2006, 14:19
tack för svar.
danjel, ehm... det finns inget av värde som är utanför denna tråd tror jag.
Berätta gärna mer.

Alltså personligen skulle jag inte för lägga mycket tid på de punkter du tar upp om de inte just nu är ett konkret problem, (och om du inte har mycket tid )
försöker alltid fokusera på databasdesign och indexering och, om så behövs, genomtänkt denormalisering eftersom där kommer problemen främst att upptå vid många användare

Vad gäller skalbarhet så tänk på dels att inte använda de inbyggda sessionerna eftersom då lagras de fysiskt på servern, vilket inte gör att nästa request för en användare kan skickas till en annan (lastbalanserad) server
Vad gäller databas, kolla på replikering,alltså se till att du inte gör "konstigheter" (beroende på vad du kör php,asp) i databasanropen,designen så att det blir svårt(tidskrävande) att börja med replikerade servar

[totoo]

grazzy: Nja, inte direkt... Just browser caching är något som jag vill diskutera också, men inte precis nu. Tack iaf!

Danjel
Det är svårt att avgöra vad som anses vara för mycket tid, men jag är väldigt noga med koden jag lägger ut och jag har sett tydliga resultat av optimeringar jag har gjort. Vid två tillfällen har jag fått en scriptgenereringstid på ca 10% av ursprungstiden genom optimimeringar enbart på phpsidan. Så visst är det viktigt att ha bra kod, och cacha noga.

Men databashistorien är ju en helt egen del, och där är jag väldigt svag och har mycket att lära. I dagsläget har jag ingen koll på alls hur de databasrelaterade delarna hänger ihop med skalbarhet och replikerade servrar. Jag har ingen inblick där och därför har heller inte min databasdesign utformats med replikering i åtanke.

Jag använder också de inbyggda sessionerna i php. Jag har hört att de är bristfälliga just av samma anledning som du säger, men jag har också hört att det ska gå att lösa relativt smidigt. Jag kommer inte ihåg vad det var för lösning, men jag läste en diskussion någonstans med någon som hade ditt argument, som sedan blev motargumenterad och tystad. Jag vet inte om det handlade om någon delad sessionskatalog eller nåt sånt - men det kanske ändå är en dum lösning.

I alla fall - vad skulle du föreslå för alternativ till mig?

Jag kan tänka mig att min databasdesign inte är i världsklass. Men jag jag har index på alla fält som ska ha index i alla fall. Sedan går det kanske att ta det där på djupare nivåer än vad jag känner till, jag kör bara index på fält som jag hämtar och sorterar enligt (where, order by).

Genomtänkt denormalisering... Ja, jag tror den är genomtänkt, kan du kanske utveckla det där?

Jag använder ju php/mysql.

Kan man kanske få be om ett exempel på vad som vore en konstighet så att jag gör det svårt för mig när vi ska sätta upp fler servrar?

Stort tack danjel, kul med komptetent folk!

[danjel]

Vad gäller sessioner, jag brukar
lägga in dem i konstanter:
SESSION_UID = $_session['uid']
eller funktioner
session_uid(){ return $_session['uid'] }
och sedan endast referera till konstanterna i koden,så att det blir lätt
att byta sessionsteknik..
Men annars skulle rekomendera att lagra sessions_id i en tabell ,
ungefärlig struktur:

session_id ,
session_value ,
latest_activity

session_id skulle då matcha själva cookien, latest_activity är en timestamp och används för att rensa bort inaktiva sessioner