Helt vild langsomt...

Ib Leif:

Lundsby: Kan du fortælle lidt om hvad problemet er/var? Det er lidt spændende at følge med når man selv arbejder med ".NET stakken".

Som du sikkert ved så er App Pool'en man afvikler i bare nødt til recycle nogle gange, sådan er det man kan ikke rigtigt gøre noget ved det, under et recycle bliver memory med cache etc. clearet, det betyder at .Net applikationer typisk er svage lige omkring deres recycles, når man kombinerer det med et site som Amino, med rimeligt meget trafik, og en naturlig reaktion fra brugere der hedder hvis mit request behandles langsomt så sender jeg bare et nyt afsted, så kan man hurtigt se hvordan et system let når sit breaking point, og lægger app poolen ned igen, etc. etc.. Det er det vi mener skete i mandags.

Det vi har gjort for at forbedre situationen, er at lave Amino om til en såkaldt web garden, hvor i stedet for den kun afvikles i en app pool, så afvikles den i fire. En for hver kerne i serveren, det betyder at når en App Pool recycles, så bliver nye requests behandlet af de andre, uden nævneværdig performance impact.

Der er selvfølgeligt også en række ulemper ved Web Garden, som gør at det bestemt ikke er alle apps, hvor det lige kan aktiveres, men for Aminos tilfælde var arkitekturen heldigvis umiddelbart sådan at vi lige kunne slå over.

Men som sagt, så er arbejdet med Amino performance langt fra slut, og der er en masse forskellige tiltag som Aminos udviklere vil indføre i den nærmeste fremtid, f.eks. prekompilering, optagelse og genskabelse af spidsbelastninger på test server, forbedring af error logging, vi har installeret New Relic og vil pinpointe de steder på Amino, der tager længst tid, når de er fundet vil vi via DotTrace systematisk få dem speedet markant op. Målet er selvfølgeligt at leverer et stabilt og markant hurtigere Amino, og det mener jeg bestemt er realistik at nå!

Ib Leif:

Lundsby: Tak for god forklaring. Må vist hellere læse lidt op på "web garden".

Det er en god ide!

Det der aldrig rigtigt står i bøgerne, er at det typisk er serialization hastighed, der ender med at sætte en brat stopper for web garden drømmenene. Det er fordi at man ved web-garden er nødt til ikke at køre inproc session state, hvilket betyder at man skal serialisere sin session state frem og tilbage ved hvert kald. Det kan nemt tage optil flere sekunder, afhængigt af sessiondatas objekt-kompleksitet.

Hvis ikke sessionstate er voldsom, så kan man komme uden om noget af det ved at skrive sin egen serialization motor, det har jeg gjort et par gange, men det er rimeligt komplekst og gav ihvertfald mig et par overraskelser undervejs!

Det smartest er bare at lade vær med at bruge shared state, under webgarden men så er det farvel til session :-)

Hejsa Lundsby

Jeg har nu aldrig hørt om mange sekunders serialization af state-data alene, men jeg kunne forestille mig, at hvis I kører hele det aktuelle objekthierarki over databasen, så forstår jeg det muligvis :-)

Hvor meget fokuserer I på koden fremfor server-setup'et?

Mener I, at sløvheden i mandags skyldtes gentagne recycles af app pool'en? Jeg synes, at det lyder meget mærkeligt. Jeg kan selvfølgelig kun være enig i, at recycle af app pool vil give problemer i længden, men ved I hvorfor der blev recyclet?

Mvh

Jens