Hej! Varför gå mot servern hela tiden? Hur menade du annars att jag ska göra? Att bara ha postback för att svara på händelser på klienten med serverkod anser jag var mycket fel. En webapplikatione är ingen "rik klient". Då bör man istället övergå till Java(Tyvärr microsoft är inte platformsoberoende). Det är inga som helst problem att arbeta mot IIS och asp.net med den lasten. Datainmatning påstår jag är långt från att vara en rik klien. Var vänlig att inte misstolka det jag skriver. Om du är osäker på vad jag menar. Be mig förtydliga det jag sagt. Sidan ska både kunna visa och ta emot data från användaren. Ofta stora tabeller eller linkade. Om du inte löpande vill ha uppdateringar hela tiden utan att användaren laddar om sidan så behöver du ingen IFRAME.Hantera stora datamängder/Många samtidiga användare i ASP.NET
Vilket är det bästa sättet att bygga ett system i ASP.NET där ca. 1000 Samtidiga användare ska kunna arbeta med formulär som ska sparas till DB(SQL server).
Är det hållbart att göra postback så fort man gör något på siden eller ska man använda något script-språk för att hämta och skicka data(via en Iframe eller liknande).
Jag har bara gjort mindre system där kanske max 25 använadre samtidigt kör mot servern, IIS btw, men skulle vara tacksam om någon hade lite tips om detta. Kanske finns det något inbyggt i .NET
//Mvh Tom OlssonSv: Hantera stora datamängder/Många samtidiga användare i ASP.NET
Sv: Hantera stora datamängder/Många samtidiga användare i ASP.NET
Måste ju hämta data från SQL-servern tex.Sv: Hantera stora datamängder/Många samtidiga användare i ASP.NET
Websidor skall var enkla formulär vilket inmatad data kan valideras av javaskript på klienten och där efter skript på servern. Finns en del verktyg för det i ASP.NET. T.ex. om man använder validerings kontrollen på ett korrekt sätt.
Bara för att det går att göra något, betyder inte att det är "rätt"!
Rätta mig om jag har fel. ;o)Sv: Hantera stora datamängder/Många samtidiga användare i ASP.NE
Vill du endast mata in data? Eller skall du presentera data också? Är det möjligt för dig att cacha den datan som skall presenteras?
Java är desstom overkill för ett inmatningsformulär och kräver att Java VM är installerat på klienterna. du kan enkelt förlita dig på Valideringskontrollerna för att validera inmatningen på klient sidan, räcker inte det kan man ta till JavaScript för att hjälpa till lite mer eller vill ha rikare klienter.
Det finns 2 saker du måste tänka på.
1 - Presenationen, vad presenterar du och hur mycket kan du cacha?
Cacha så mycket som möjligt.
2 - Inmatning, påverkar en användares inmatning någon annans ur ett dataintegritets perspektiv?
Se till att du använder dig av rätt inmatningslås och rätt dataintegritets-kontroller vid datakällanSv: Hantera stora datamängder/Många samtidiga användare i ASP.N
Sv: Hantera stora datamängder/Många samtidiga användare i ASP.NET
Att cacha data är nog inte möjligt i detta system då det en användare gör måste redovisas för andra när sidan laddas om.
Jag hade tänkt att med en iframe och JScript hämta endast den data som ska uppdateras och bygga HTML-koden med Jscriptet, men det kanske inte är nödvändigt eller hållbart att lösa det så?Sv: Hantera stora datamängder/Många samtidiga användare i ASP.NE
I övrigt så gäller det att designa din lösning med skalbarhet i åtanke, dvs hårdvaran skall vara den enda flaskhalsen i ditt system ( det finns faktiskt en fysisk gräns för hur många användare en p4:3GHZ med RAID SCSI och 2GB minne klarar, även om den är väldigt hög). Det gör nämligen att du verkligen kan hantera fler användare om du sätter i mer minne eller ställer till en burk i en WebFarm.
Vad gäller databasen så kan du möjligen partionera ut datan på olika hårddiskar på samma dator eller ut på flera servrar. Men det kan mycket väl bli overkill. Beroende den verkliga storleken av systemet.
Några generella råd som bör gälla i alla system igentligen, men effekterna av att strunta i dem blir mer tydliga i system med hög last.
- Lås inte data i onödan, skapa alltså inte hårda transaktioner ex Seriliazable i databasen om du inte har svåra data integritetsproblem.
- Hanterar dina resurser så effektivt som möjligt, dvs släpp handles, lås, connections osv så fort det bara går.
- Normalisera databasen, om inte i 3:e graden så i alla fall 2:a.
- Jobba med databasintensiva operationer så nära databasen som möjligt. Ex SELECT, INSERT, UPDATE, DELETES i stored procedures (SELECT med JOINS kan du lägga i vyer också).
- Undvik COM+ / MTS så länge du kan, om du inte verkligen behöver någon av tjänsterna de erbjuder.
Det är svårt att ge mer specifika svar på en sådan generell fråga, att sätta upp en skalbar arkitektur utan att ha mer detaljer om kravspecifikationen på systemet är näst intill omöjlig.
Tex, när du pratar tusentals användare, vad pratar du för tidsintervall då? På en dag? På en timme? På 1 sekund. Det är ganska stor skillnad. Av dessa användare, hur många idlar, dvs tittar bara på datan utan att göra något? Hur många av dem matar in ny data och i vilken mängd? Gör varje användare en inmatning eller hundratals?
Är det bara ny data som kommer in och skall presenteras? Eller är det uppdateringar också?
Hur ska datan presenteras? Skall den nya eller uppdaterade datan bara visas om användaren uppdaterar sin sida? Eller har användaren ett fönster uppe där han/hon kräver sekundvisa uppdateringar så nära realtid som möjligt av vad som händer i DBn?
Är kraven samma på alla delar av applikationen? Eller kan olika delar ha olika svar på ovanstående frågor?
Det här är några av frågorna man måste ha klart för sig innan man kan titta på en mer specifik design av ett system.