I skalbara system med hög last är det nästan alltid databasen som blir flaskhalsen och som segar ned. Det är tyvärr också databasen som är det knepigaste att skala up.

Som Jim var inne på kommer man väldigt långt med ganska enkla medel.

En hyfsat kraftfull VPS kommer man långt med om har bra queries och mycket cache av databasanrop samt OP-code cache.
I normala fall kan man se till att man nästan aldrig läser något alls ifrån databasen utan endast ifrån minnescachen(t.ex. memcached eller redis). Om man ser till att varje gång man gör någon ändring i databasen (INSERT, UPDATE, DELETE) också direkt uppdaterar cachen kommer man också kunna serva det senaste innehållet utan att röra databasen samtdigt som du har en lång(flera dagar, eller till och ned en månad går utmärkt) TTL(time to live, dvs hur länge cachen ska räknas som aktuell) på cachen. Databasen kommer därmed mer eller mindre endast hantera skrivningar och alla läsningar hanteras av cachesystemet. Detta gör systemet extremt snabbt och kräver väldigt lite CPU-resurser, men det kräver dock en del minne beroende vad det är för site.

Ett enkelt steg är sedan att gå ifrån en (VPS-)server till två är att separera databasen ifrån webbservern. Då är det bara att ändra MySQL-hostname i koden så fungerar det.

När inte detta räcker blir det ju som sagt mer komplicerat. För att lastbalansera HTTP-requests så tycker jag den klart bästa läsningen är Varnish. Varnish-servern ligger framför webbservrarna och cachar hela requests som skickas tillbaka direkt om sidan finnas cachad. Därmed behöver inte en request hanteras alls av webbservern om den redan finns cachad. Det är heller inga problem att sätta upp flera varnish-servrar som arbetar parallellt(det enklaste är round-robin DNS, men det finns mer avancerade alternativ för att hantera flera varnish-servrar). Bakom varnish-servrarna kan man sedan ha obegränsat antal webbservrar.

För databasen blir det någon klustrad lösning med replikring som redan nämnts och förklarats bra här.

Jo har också en känsla av att databasen är det som är bökigast, men en bra början är som du säger att man bryter ut databasen till egen dedicerad server.

Tack alla för era tankar och idéer. Jag återkommer när detta blir aktuellt (dvs när/om jag kommit på "the next big thing" ;-)

Gällande att ha flera varnish-servrar parallellt ta en titt på http://www.fastly.com/ och deras API. De gör just detta. Du får även geo-targetting och eventuellt redundans.

Du behöver inte "the next big thing". Ett befintligt projekt funkar gott och väl. Det är väldigt lärorikt att lasttesta och optimera utifrån resultaten. Det borde inte dröja länge förens du inser att mikrooptimeringar som if vs switch, for vs while eller allt vad det kan vara inte spelar någon roll i det stora hela. Dessutom är det riktigt kul! :)

Mitt nuvarande projekt har ca 100.000 sidvisningar den senaste månaden vilket inte ens är i närheten för att få min vps hos glesys att börja höja pulsen, så för tillfället är jag "all set" ett tag framöver. Gissningsvis kan servern hantera det 10-dubbla eller mer innan det är dags för seriös optimering. Problemet med optimering under last är just lasten. Jag antar att man får köra en sluten test-miljö där man laddar diverse funktioner/sidor ett antal tusen gånger och mäter tiden emellan optimeringarna.

Ja, vill du göra det ordentligt behöver du en labbmiljö som är så lik livemiljön som möjligt som du kör testerna mot. När den är på plats kan du sätta upp "agents" som belastar sajten om det inte räcker med en enskild maskin. Du kommer behöva sätta upp mål, t.ex. att sajten alltid ska svara inom n sekunder, att CPU-belastningen inte går över en viss gräns etc eftersom man inte kan optimera kod i all oändlighet; nånstans når man en gräns för vad ens hårdvara klarar av.

De flesta lasttestningsprogram kan spela in scenarion/användarfall som man sedan spelar upp men förstärkt (simulerade användare). Det går att fejka väntetider, bandbredd, ordningen på scenariona etc. Ganska flexibelt som borde återspegla verkligheten ganska bra med andra ord. Man hookar upp "lyssnare"/grafer på vad man är intresserad av, t.ex. minnesförbrukning, CPU-användning, request/sec, antal köade requests, felsidor etc. Ser du någon sida som presterar dåligt kör du igång en profiler och tar reda på vad tusan som faktiskt tar tid, vilka metodanrop som roffar åt sig all prestanda. Fokusera på de stora problemen först.

Att vänta tills du har nästa stora grej tror jag inte på. För det första kanske man aldrig hittar något sånt projekt, sen om/när man väl är där har man kniven på strupen och kan inte analysera resultaten i lugn och ro. Långsiktigt bra beslut tar man oftast inte när man är stressad.