Vi jobbar nu med ett större intranät som till mycket kan liknas med hur en vanlig community ser ut. Vi planerar med att användarantalet kan vara Mycket stort.
Vi jobbar med en tre-lagers arkitektur i .Net 2.0.

Frågor vi kommit att tänka på:
- Hur mycket skall cachas?
-- Vi använder inte .Nets membership provider. Vi sparar idag endast den kritiska användar informationen i sessioner samt även ett objekt med användarrestriktioner. Hur mycket information är lämpligt att cacha, och när blir cache en börda?

- Intranätet skall lanseras i flera språk och vi använder resources för att sätta texter på kontroller etc. Hur hanterar .Net dessa anrop? Cachas dessa på något sätt? Skulle man på app_start kunna läsa in alla resource filer i cache och blir det någon nytta med det?

Ge mig lite feedback kring detta och gärna länkar/böcker kring större liknande projekt.
MVH
Robert

Cacha så mycket som möjligt.

Session är antagligen ok men tänk på att det kostar minne. Iofs gissar jag på att ni har en server bestyckad med minst 2GB RAM och då ska inte ett par tusen sessioner orsaka problem. Sänk eventuellt session timeout till högst ett par minuter (se då till att er sessionsinfo återskapas från db automatiskt utan att anv. måste logga in igen).

Du kan cacha mycket eftersom ASP.NET sköter om cachen och rensar efter behov (förlita dig inte på att information alltid finns i cachen). Nu pratar jag alltså om Cache-objektet.

Resources är inga problem, har du kompilerat på default vis med Visual Studio så kommer resources att vara inbakade i en DLL alltså de lever i minnet.

Det finns många artiklar på nätet om ASP.NET performance... Googla :)

Tackar för input.

Vad gäller artiklar så tänkte jag specifika artiklar kring vad man skall tänka på kring stora projekt. Har funnit några böcker som behandlar det bra.

Annars är det oftast böcker som behandlar generella tips för web utveckling. Jag söker mera specifika .Net 2.0 för stora projekt.

>Cacha så mycket som möjligt.

Nja... vågar faktiskt säga att cachea för mkt kan även det leda till problem...
Cache är inte alltid en lösning... Sedan kan man ju "cacha" på olika nivåer...
Ex är det oftast ingen vinst att göra data som uppdateras ofta cachat. Cache kan istället bli en
overhed då man helt plötligt skall ta hänsyn till denna vid läsning och skrivning logick som kan ta dataprestanda...

Så man skall vara lite föriktig med att cache is the silver bullet.

Ja, lite slarvigt uttryckt av mig. Menade egenligen:
Cacha så mycket som möjligt av det som 1. Inte uppdateras ofta, 2. Läses ofta.

Jo absolut, det är ju de självklara svaren. Det jag är mera ute efter mera befintliga lösningar som man kan kika på alt. artiklar och böcker. Jag vet hur man programmerar och på ett ungefär hur saker skall cachas.

T.ex. hur hanterar .Nets Membership provider cache? Vad cachas där? User objektet cachas men vad mera?

Om jag bara drar till med lite funktionalitet så kanske vi kan diskutera vad som kan/bör cachas.
- En diskussionsplattform, typ forum. Vad kan cachas (Kan nått cachas egentligen?)
- Bildlagringsplattform, typ bildarkiv.
- Personlig blogg
- Kontaktnätverk (Typ "vännerlista")

Dess funktionalitet kommer ju ligga på separata sidor så som jag ser det, är det kanske inte nödvändigt att cacha?

Återkom gärna med artiklar och böcker som sagt, om det finns?

Läste en bok som bedrev ett 3-lagers projekt, "The beer house" hette lösningen. Det var intressant att få en insikt i hur författaren ville skapa det. Mera sånt.

Det du bör tänka igenom när ni utvecklar är ju att kod som anropas ofta är optimerad på alla sätt och vis, hålla antalet svängar till databasen nere och speciellt upp- och nedkopplingar eftersom dessa är kostsamma.

Vidare bör ni självfallet se till att databasen är klokt indexerad så att frågor inte "hänger" sig. Titta gärna på asynkrona anrop till DB och även AJAX, vilket ju får användaren att uppleva sidan snabbare om valda delar laddas asynkront och dessutom minskar lasten på webbservern eftersom färre request behöver tas emot.

Sedan finns det ju ett antal parametrar i IIS:en att tweaka på om ni känner att det är nödvändigt; App Poolens inställningar, machine.config ändringar för att öka antalet requests per processor, web gardens etc.

Tänker ni använda er av lastdelning? Tänk då på hur ni sparar user sessioner så att dessa inte förloras vid hopp mellan servrar.

Kan rekommendera er att köra lasttester kontinuerligt på koden så ser ni om det är en flaskhals någonstans. Mercury Loadrunner är väl bäst, men absolut inte gratis. Inbyggt i Visual Studio Team Edition finns det ett verktyg för lastsimulering men det finns också gratis verktyg som är roddiga som OpenSTA.

Lycka till!

Mvh David

Jag skulle vilja säga att man inte ska cacha eller "tweaka" något överhuvudtaget fram tills man stöter på ett problem. Självklart behöver man ju inte göra rena dumheter i sin kod men att jaga prestanda innan du ens satt systemet i acceptans-test är att hoppa i galen tunna. Det är i princip omöjligt att direkt veta var dina problem kommer att uppstå.

Men om du tycker att du kan se in i framtiden som värsta oraklet, ja då kanske ;)

Jag ska be att få tacka för svaren. Det är intressant att se att folk resonerar ganska olika.

Nej, vi kommer troligen att använda en server.

Jag har inte Team Edition utan Professional. Jag ska prova OpenSTA omgående.