En session skapas hos både klienten (i form av en cookie) och på servern och ser till att dessa två stämmer överrens. Man kan t ex få fram ett unikt ID-nummer för sessionen. När man kliver in på en sida första gången startas en session automatiskt (som i viss mån kan styras i Session_OnStart i global.asa). Efter en stund försvinner sessionen (standard 20 minuter, ställbart) när användaren inte gjort någon mer åtkomst till en sida på servern.
Många sessions som innehåller mycket data slukar prestanda, så man bör inte använda sessions (eller cookies) för något annat än att spara sådant som är nödvändigt för den aktuella användaren (t ex användar ID, senast besöksdatum, produkter i en varukorg etc). Spara aldrig några objekt i en session, t ex databaskopplingar, för då skapas ett nytt objekt för varje användare!
En cookie är en textfil som enbart sparas på klienten och är kopplad till en eller flera servrar.
När du ska välja mellan dessa två så är det som allt annat; det beror på vad du vill göra. Men du kan ställa dig en enkel fråga:
Behöver jag identifiera eller "logga" när en användare kliver in & ut från webbapplikationen?
Om du svarar nej så finns det egentligen ingen anledning att köra med sessions. Kör då med cookies istället! ;)
Pace:
Man alltså, jag har på nåt sätt fått för mig att folk verkar föredra att använda cookies istället för sessions. Du vet alla säger att sessions är onda osv .. :) .. men jag tycker det verkar oherhört märkligt om inte sessions och cookies bygger på exakt samma teknik .. och skillanden är ungefär att när man sätter .expire på cookien så skriv det till den lokala datorn ..
Aja .. jag spekulerar mest .. men det är lite lamt att folk tjatar så mycket om att sessions är onda osv när det finns så jävla mycket "allvarligare" perforamnce grejjer man kan göra fel i asp .. fast ok .. att lägga objekt i sessions är väl bra att folk påpekar att man inte ska göra ..
En session är något som servern håller reda på, alltså en liten del av processen IIS, på windows-burken, alltså servern. Den är aktiv och innehåller sitt värde i RAM-minnet sålänge som sessionen är aktiv. Har du en applikation med säg.. 1000 användare, och du kanske har klantat till det och använt tre stycken sessioner vid inloggningen, som alla är bundna till användaren. Då har du helt plötsligt 3000 sessioner att hålla reda på om alla är inloggade samtidigt, och eftersom alla inte alltid loggar ut, utan ibland bara stänger webbläsaren, kanske inte ens den skrämmande siffran hälften är aktiva. Du har alltså 1500 värdelösa poster i minnet som bara suger resurser som behövs på nåt annat. Detta är ett värdelöst exempel, men du förstår iallafall varför man kanske skall vara lite försiktig med sessions.
En cookie skrivs till klienten och sedan är det klart. Punkt slut. Servern skiter fullständigt i ifall du har femhundratusen cookies eller noll, den funkar lika bra ändå.
Har det inte med en inloggning eller viktig data (som ändå inte skall lagras i sessions) att göra; använd cookies och inte sessions. Inloggningssystem däremot, då är det användbart, men det räcker med en per användare.
Sessionsvariabler är ju kontextberoende, så varje besökare får ju ändå sessionsobjektet initierat. Om det då är 1 eller 5 st spelar mindre roll, eftersom visst minne ändå allokeras, och finns där.
Man bör också tänka på att en session är standard 20 minuter (detta noga uträknat med statistik av Microsofts tekniker). Ska man räkna och försöka ge exempel, så måste man ta med tiden i beräkningarna, typ 1000 besökare/ timma, och sedan besökarnas medelanslutningstid (kanske 20 minuter). Jag vet, det slutar med beräkningar på "teoretiska" besökare, och detta är inte speciellt användbart. Enbart ett stresstest kan visa om det är okey eller inte, men dessa stresstest är beroende av hur många domäner som finns på aktuell server.
Tänk även på att IIS är ju gjord för att hantera sessioner, och det är dumt att inte använda denna teknik, dock med måtta.
Har jag tid över, så skulle jag kunna göra stresstes med 1000 personer under 1 timmas intervall, och återkomma med detta (obs, när jag har tid). Men jag tror knappast att 1 eller 5 sessionsvariabler slöar ner något alls (så länge det handlar om rena variabler, inte arrays och klasser). Det bör gå att räkna fram ett brytvärde, dvs ett medianvärde där ett antal sessionsvariabler bromsar prestandan sidor/min.
Om man tar OveRRidEs exempel om 3 000 sessioner så kan man ganska enkelt kalkulera hur mycket minne de slukar. Varje session tar ett par byte i minne vid initiering, minns inte exakt hur mycket, men vi kan dra upp det rejält och säga 1024 byte (1 kB)! Varje användare får data slängda på sig med motsvarande storlek. 2 kB för varje användare och totalt fanns det 3 000 aktiva sessioner. 2 kB x 3 000 sessioner = 6 000 kB = ca 6 MB.
En server är väl knappast konfiguerad med mindre än 256 MB i minne och då inser man att sessioner inte drar så mycket prestanda, även om kanske 10 sajter på samma server slänger ur sig så mycket data.
Dessutom (om jag minns rätt) lagras all data på klienten och endast det unika ID-numret är kopplat till servern. Så att påstå att sessions är onda är lite att ta i. Men behöver man inte använda sessions så är det god sed att inte göra det - det är alltid bäst att göra rätt från början.
Toonster skrev:
Sessionsvariabler är ju kontextberoende, så varje besökare får ju ändå sessionsobjektet initierat
btw .. var sparas såna cookies som man inte sätter expire date på .. de verkar inte ligga i standard foldern för cookies iallfall .. tänkte på säkerhets aspekten om man använder såna istället för sessions .. jobbit om folk är inne och pillar i dom ..
Bra tråd! Lärt mig lite om cookies och sessions! Har själv en community med ca 1000 användare. När en användare loggar in skapas 17 sessions. Min fårga är: Slöar det ner sidan?
17 sessions låter väldigt mycket, och visst suger det lite kräm.
Med "bara" 1000 användare ska det nog inte vara några problem (visserligen säger du inget om antalet samtidiga användare), du kan ju själv räkna ut hur mycket av serverns RAM som går åt till att hålla koll på dina sessions.
Det är dock ett bra tips att försöka hålla nere antalet sessions.
Tycker att man får se till alternativen med sessioner eller ej. Idag så är hårdvara som t.ex. minne relativt billigt och personligen tycker jag att fördelarna med att använda sessioner överväger kostnaden för att köpa in mer minne.
Alternativet är ju att man får skriva en egen hantering av cookies vilket kan ta sin lilla tid och kosta mer än att köpa in 1 Gb RAM...
Sen så skadar inte en sund sessionshantering. Man behöver ju inte belasta servern i onödan.
Ska man tänka stort och inte begränsa sig till att bygga små amatörsaker hela livet så ska man inte bygga applikationerna med tanke på att de ska köras på något gratiswebbhotell eller liknande.
Skall man tänka stort bör man inte använda sessioner rakt av då dessa inte klarar av webbfarms-fallet. Dock finns det färdiga komponenter som fixar detta.
Alternativet är att gå över till ASP.NET med dess utbyggda sessionshantering.
130 ms totalt · 3 externa anrop · v20260731065814-full.b746b907
