i debat
Bliv gratis medlem på Amino

Nye ekspertblog-indlæg Hjælp & support til Amino services

Læs flere ekspertindlæg
 

Top karmaliste (30 dage)

De flinkeste Amino’er der hjælper mest med "Hjælp til Amino's services"

 

Helt vild langsomt...

Side 5 ud af 5 (45 indlæg) < Forrige 1 2 3 4 5
Amino-karma 19.473
Fra Hellerup
Tilmeldt 11. apr 06
Indlæg ialt: 3.522
Amino Plus
Lundsby
Fra CloudSprout
Skrevet 11-04-2012 kl. 08:13

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å!

Med venlig hilsen
Peter Lundsby

Spring programmøren over!

Amino-karma 741
Tilmeldt 7. jun 06
Indlæg ialt: 160

Ib Leif
Skrevet 11-04-2012 kl. 08:29

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

Amino-karma 19.473
Fra Hellerup
Tilmeldt 11. apr 06
Indlæg ialt: 3.522
Amino Plus
Lundsby
Fra CloudSprout
Skrevet 11-04-2012 kl. 10:39

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 :-)

Med venlig hilsen
Peter Lundsby

Spring programmøren over!

Amino-karma 1.554
Fra Aarhus C
Tilmeldt 6. sep 10
Indlæg ialt: 409

Jens Juul Nielsen
Fra Jens Juul Nielsen
Skrevet 11-04-2012 kl. 10:51

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

Amino-karma 19.473
Fra Hellerup
Tilmeldt 11. apr 06
Indlæg ialt: 3.522
Amino Plus
Lundsby
Fra CloudSprout
Skrevet 11-04-2012 kl. 11:09

jjn:
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 :-)

Bare smæk en god sjat af de indbyggede generic collection klasser i, så har man et par sekunder.

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

Det er altid en helheds betragtning, her tog vi udgangspunkt i det konkrete problem hvor App Pool'en havde meget svært ved at komme op igen. Men der er flere andre flaske halse steder som der også skal kigges på.

jjn:
Mener I, at sløvheden i mandags skyldtes gentagne recycles af app pool'en? Jeg synes, at det lyder meget mærkeligt.

Det er meget naturligt i en app, der i afhænger af cache. AppPoolen nulstiller cachen så den skal bygges op igen, hvis den så samtidigt rammes af en masse requests for du formendtligt en masse der prøver at bygge samme cache, hvilket sandsynligtvis åbner posen for en masse parallel programmeringsproblematikker.

jjn:
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?

IIS'en er designet til at recycle app poolen, det er en situation som man hverken kan eller bør forhindre. Som standard recycler den faktisk hver 29. time (så vidt jeg husker)
Så det eneste der er at kører er at designe sin app, til at kunne klare disse recycles.

Teoretisk kan man sige, at det er for dårligt at .Net er designet sådan, og alle da bør skive kode der ikke leaker, garbage collectoren bør være perfekt etc. men hvis man vil lave ting der performer i den virkelige verden, så er det bare at lærer at leve med det :-)

Med venlig hilsen
Peter Lundsby

Spring programmøren over!

Side 5 ud af 5 (45 indlæg) < Forrige 1 2 3 4 5

RSS-feed