Jag har ett projekt där antalet användare är uppskattat till ca 100.000 st. Applikationen är en slags tävling där användarna ska logga ett antal parametrar och svara på frågor, mao posta ett antal formulär till servern. Baserat på resultaten ska en massa statistik genereras. Statistiken ska helst genereras i realtid, dvs räknas om så fort någon användare uppdaterar sina resultat.

Beställaren tror att majoriteten av användarna kommer att göra det här på måndagar, och främst på morgonen, och är lite orolig för kapaciteten.

Så för att vara på den säkra sidan behöver jag lite tips för att dimensionera systemet. Om man antar att alla 100.000 går in inom loppet av en timme blir det 100.000 / 60 min / 60 sek = 27 posts/sek, men det kan ju bli mycket högre antal per sekund än så.

Tror att kunden har en webfarm med två servrar och ytterligare en dedikerad SQL Server. Räcker det till för worst-case-scenariot?

Hur pass effektivt och snabbt är det att använda SQL Server för Sessionhanteringen i en webfarm? Antar att jag måste minimera all Session-användning, men iaf... Det kommer nog att bli en del AJAX, så jag kommer att behöva något som kan hålla ordning på state.

Vilka problem med låsningar kan jag tänkas få om 10.000 användare ska skriva till samma tabell samtidigt?

Finns det några problem med att använda cache-objektet i webfarm-miljö? Jag vet att att det inte synkas mellan servrarna, men det borde ju inte vara något problem om man använder en väldigt kort timeout.

Jag kommer inte att använda någon O/R mapper och jag har full kontroll över databasen och IIS:erna, så alla lösningar är välkomna!

[citerat Fredrik Holm Medlem:18869 www.pellesoft.se/communicate/forum/view.aspx?msgid=267400&forumid=10&sum=0#267400]
<b>> Tror att kunden har en webfarm med två servrar och ytterligare en dedikerad SQL Server. Räcker det till för worst-case-scenariot?</b>

Det beror på vad som ska göras på de där sidorna ;)

[citerat Fredrik Holm Medlem:18869 www.pellesoft.se/communicate/forum/view.aspx?msgid=267400&forumid=10&sum=0#267400]
<b>> Hur pass effektivt och snabbt är det att använda SQL Server för Sessionhanteringen i en webfarm? Antar att jag måste minimera all Session-användning, men iaf... Det kommer nog att bli en del AJAX, så jag kommer att behöva något som kan hålla ordning på state.</b>

Så fort du inte kör inproc så kommer sessionstaten att behöva deserializeras vid varje sidladdning, och ev. serializeras om någonting ändras i staten. Ett tips kan ju vara att inte lagra stora dataset i sessionstate ;) Sen när det gäller att koppla på SQL server; det blir ju en extra vända till sql-servern vid varje sidladdning, samt ev en till om någonting ändras i den, så worst case är väl två extra vändor till sql-servern per sidladdning. Frågorna som ställs på sql-servern är dock relativt lätta så vitt jag minns, mest att skyffla ren data fram och tillbaka.

Det stora problemet med en massa vändor fram och tillbaka är att det blir fördröjningar överallt, vilket kommer käka trådar, vilket tynger ner iis som kan behöva stå och stampa för att det inte finns några lediga trådar, så om du kan köra på Win2k8-servrar så skulle det nog komma väl till pass då de inte riktigt har begränsningen en anslutning=en tråd i iis längre.

Vidare, om du tänker dig att siten kommer bygga på AJAX så antar jag att siten inte kommer bry sig om läsare utan javascript? Om så är fallet så skulle det kunna vara värt att t.ex. titta på möjligheten att skicka en stor mängd frågor i en javascriptarray till klienten, som sedan får rendera alltihopa, ev. visa flera sidor och hela det köret, för att sedan posta till servern när man är klar. Det skulle kraftigt begränsa mängden anrop mot servern.

Vidare, man skulle kunna tänka sig att du skulle kunna posta bara resultat rakt av ibland till t.ex. en ashx-sida utan sessionstate, och att du sedan lägger till en parallell tabell till sessionstate-tabellen i databasen, där samma sessionid som i sessionstaten används som nyckel, och där du kan ha fält för t.ex. användarid eller vad du nu har, för att på så sätt i en enda fråga till databasen kunna lämna in svar eller liknande - en sådan konstruktion skulle då nämligen inte kräva att sessionstaten används på just den sidan, och således gå från 2-3 databasanrop till 1 databasanrop.

Precis som du antar kommer vi att förutsätta att besökarna har javascript aktiverat. Och så mycket som möjligt kommer att samlas ihop innan postback. Dessutom blir nog maximalt två, tre postbacks per användare, och det inom loppet av ett antal minuter (också per användare).

Det låter som att Session ska undvikas till varje pris. Synpunkten om Win2k8 servrar är också bra, ska ta upp det med kunden.

Ashx-idén låter intressant, men faller inte det konceptet på att varje besökare vill ha omedelbar feedback på hur han/hon står sig i tävlingen? Varje uppdatering kommer att förändra åtminstone någon del i statistiken.

[citerat Fredrik Holm Medlem:18869 www.pellesoft.se/communicate/forum/view.aspx?msgid=267400&forumid=10&sum=0#267404]
<b>> Ashx-idén låter intressant, men faller inte det konceptet på att varje besökare vill ha omedelbar feedback på hur han/hon står sig i tävlingen? Varje uppdatering kommer att förändra åtminstone någon del i statistiken.</b>

Jag har då ett förslag: Skippa sessionstate och bygg en egen, helt anpassad, som inte kräver mer än en enda transaktion mot databasen, det borde inte vara för svårt tycker jag? Någon storedproc som kan kolla sessionid mot användarid, uppdatera svaren och returnera statistik? Om du sedan bygger ajax på det så borde det bli ganska effektivt; klient -> asp.net -> sql -> asp.net -> klient i rak följd. Om inte annat så skulle det räcka om svarsdelen bygger på det här, allt runtomkring skulle ju kunna bygga på vanlig asp.net om det inte är lika mycket press på det

[citerat Fredrik Holm Medlem:18869 www.pellesoft.se/communicate/forum/view.aspx?msgid=267400&forumid=10&sum=0#267404]
<b>> Det låter som att Session ska undvikas till varje pris. Synpunkten om Win2k8 servrar är också bra, ska ta upp det med kunden.</b>

Jag skulle inte säga att du måste undvika till varje pris, men du skulle kunna få ner antalet databasförfrågningar till en tredjedel per anrop, så det kan vara värt att undersöka :)

Låter bra det här! :-)

Annars verkar det finnas en hel del att tänka på, framförallt synkning av cache och loggar:

http://www.c-sharpcorner.com/UploadFile/gopenath/Page107182007032219AM/Page1.aspx

Det fanns ju inte så mycket detaljer, men det är väl bara att söka vidare...

Tack för hjälpen!

[citerat Fredrik Holm Medlem:18869 www.pellesoft.se/communicate/forum/view.aspx?msgid=267400&forumid=10&sum=0#267408]
<b>> Låter bra det här! </b>
<b>></b>
<b>> Annars verkar det finnas en hel del att tänka på, framförallt synkning av cache och loggar:</b>
<b>></b>
<b>> http://www.c-sharpcorner.com/UploadFile/gopenath/Page107182007032219AM/Page1.aspx</b>
<b>></b>
<b>> Det fanns ju inte så mycket detaljer, men det är väl bara att söka vidare...</b>
<b>></b>
<b>> Tack för hjälpen!</b>

Hur mycket är det du kan/borde cacha egentligen? Det enda jag skulle kunna tänka mig är väl frågorna? Och det skulle du rentav kunna loopa ut i en statisk fil, spara på disk, och låta iis grejja i http.sys, den cachen är grymt effektiv (körs i kärnan ;) ) Eller tvinga asp.net att cacha den där (borde gå, även om jag inte har det i huvudet)

(State server är nog bara halvbra, det är visserligen effektivare än sql server, men det är fortfarande nätverkstrafik, och serializeringar, samt.. Om den går ner precis just när det är peak så bygger det på fort; alla måste logga in igenom eftersom att alla sessions är borta)

Om du ska försöka räkna statistik på svaren i dB:n samtidigt som det sker en massa inserts så måste du använda lock hints. Annars kommer du få problem med låsningar.

T ex ska din statistik sql se ut så här SELECT SUM(Falt1) FROM Mytable WITH (NOLOCK)

WITH (NOLOCK) innebär att du inte ska låsa upp tabellen...

När det är så många användare kanske det är läge att undvika "traditionell ASP.NET arkitektur", alltså WebForms med ett gäng ServerControls och ViewState. Jag hade övervägt en handkodad micro-Ajax lösning med REST, kanske JSON, för att minimera lasten mot servern. Du behöver egentligen bara väldigt små meddelanden för att lämna och hämta info. Rendering kan skjutas ut på klienterna genom script/DHTML. Om ändå JS är en förutsättning. Dessutom får besökarna en najs experience. SQL Servern ska klara lasten utan problem om du har riktiga index osv. Glöm inte automatiserade tester!