Just nu i M3-nätverket
Gå till innehåll

Storlek på Session-variabel?


devilwithin

Rekommendera Poster

devilwithin

 

En kanske något dum fråga, men hur stort kan innehållet i en session-variabel vara? Om jag vill slänga in minarray() i session("minarray"), hur stor får den lov att vara?

 

Har sökt lite på MSDN, letade efter tekniska specifikationer, men hittade inget. Kan dock inte tänka mig att det inte finns någon som helst begränsning.. någon som vet?

 

 

- devilwithin

---

It's not nerdy to wish for a BFG10k from the easter bunny!

 

Länk till kommentar
Dela på andra webbplatser

Mr Andersson

Tror att det egentligen bara är serverns internminne som begränsar det... men ett tips är att försöka hålla det på en låg nivå...

 

Länk till kommentar
Dela på andra webbplatser

Magnus Gladh

Har för mig att jag sett att storleken på en session-variabel var 1KB. Jag kan dock inte komma ihåg var jag såg det, så ta det med en nypa salt.

 

I vilket fall som helst så spelare inte det någonroll eftersom man inte lagrar din arrayn i sessions-objektet utan en referens till en minnesarray där den ligger (om jag inte har helt fel).

 

Sedan är det som Mr Andersson säger, det är internminnet i din maskin som sätter stop för hur mycket data du kan lagra i dina session/applications variabler.

 

- Magnus

-----------------------------------------------------

Jag är inte kaxig, jag är bara så jävla bäst...

 

Länk till kommentar
Dela på andra webbplatser

Hej!

 

Session och Application lagrar variablerna i en collection struktur. Dessutom kan VBScript endast hantera Variant datatyper som per definition är 16 bytes stora oavsett underliggande datatyp. Om du lagrar en array i Session, så blir storleken 16 x antalet element. Om man sparar text värden i arrayen tillkommer även utrymmet för att spara själva texten. En Variant av subtypen String kan innehålla 2 miljarder tecken.

 

Rent teoretiskt är det minnet allokerat för processen som sätter begränsningen (2 GB), dock kommer IIS:en att dö innan man når den begränsningen eftersom sessionshanteringen tar så mycket kräm.

 

/foo

 

Länk till kommentar
Dela på andra webbplatser

devilwithin

 

Frågan är då hur mycket jag tjänar på att hämta värden från databasen och lägga det i en array (integer, inte fler än 1000 celler i arrayen) i en sessionvariabel när användaren loggat in och jobba mot dem istället för att hämta dessa värden varje gång de behövs.. är det någon poäng i att göra på det viset?

 

 

- devilwithin

---

It's not nerdy to wish for a BFG10k from the easter bunny!

 

Länk till kommentar
Dela på andra webbplatser

Hej!

 

IMO är det inte bra att spara stora mängder data i sessionsvariabler. Problemet är att IIS håller i detta data fram tills dess att sessionen förstörs (default 20 min) eller om programmet själv förstör det.

 

Frågan är vad dessa 1000 tal representerar? Är talserien unik för varje användare? Hur stor belastning på DB servern blir varje hämtning?

 

16kb * Antalet användare är kanske inte så mycket, men det är något man måste väga mot andra faktorer som ovan.

 

En viktig poäng är att inte jobba direkt mot sessionvariabler, utan plocka ut dem i lokala diton istället. Annars går dina anrop via Session objektet varje gång.

 

/foo

 

Länk till kommentar
Dela på andra webbplatser

devilwithin

 

Det handlar om att jag vid varje givet ögonblick (i toppen på sidan) vill kunna kolla om användaren har rätt att kolla dessa data som han försöker hämta. Detta för att undvika att han/hon ändrar värden i en URL och därmed kommer åt någon annans uppgifter. Som det är nu så kontrollerar jag via en funktion användarens id (som ligger i en sessionvariabel) mot databasen, men eftersom detta sker varje gång en ny sida laddas så blir det följdaktigen många kontroller. Och har jag då 300 användare inne som surfar runt.. tja du fattar.

 

Min tanke var att från start läsa in ID't på de uppgifter som användaren skall ha tillgång till i en array i en sessionvariabel, och kontrollera värdena mot denna istället för att checka mot databasen varje gång. Det verkade ju bra igår kväll när jag funderade på det, men.. tja vad tror du?

 

Vad gäller att hålla på datan så sätter jag session timeout på 5 minuter samt kör en session.abandon() när användaren loggar ut, så det bör inte vara för mycket data liggandes på servern även om dessa människor inte inte lär sig använda logout istället för kryssknappen längst upp till höger.

 

 

- devilwithin

---

It's not nerdy to wish for a BFG10k from the easter bunny!

 

Länk till kommentar
Dela på andra webbplatser

Hej!

 

Nackdelen med att använda en array är att du måste loopa igenom den för att kontrollera om ditt värde finns i den. I värsta fall kanske värdet är sist i arrayen, vilket resulterar i en dålig prestanda.

 

Förresten, har du verkligen 1000 olika sidor?? Det känns som om du har 1000 unika objekt, så borde en databas lösning vara smidigare och lättare att underhålla?

 

Dessutom gäller arrayen för hela sessionstiden, dvs. minst 5 minuter men om användaren är aktiv kan den sträcka sig betydlig längre. Jag antar att du inte uppdaterar behörigheten under sessionens livslängd?

 

Du kan använda ett dictionary object istället, där man kan söka på en nyckel (ditt tal). Tänk bara på att använda ett "multitrådat" object istället för ASPs inbyggda Dictionary object (exempelvis http://www.narfle.com/ref/3rdPartyCom/caprockDCT.zip det finns dock många andra alternativ).

 

/foo

 

Länk till kommentar
Dela på andra webbplatser

Jag har testat med att lägga Arrayer i Sessions-variabler. Storleken varierade mellan 1500-2000 rader i vektorerna. Erfarenheterna var inte goda. Vid enstaka användare orkade servern det. (500 RAM, dubbla cpu, stora diskar, flera samtidiga applikationer.)

 

Men.. när användarantalet ökade upp till 20,30 osv så gav servern nästan upp. Jag läste på MS att konstruktionen av Script-språken kräver att en fullständig kopia av arrayen skapas på minnesutrumet. Sant el inte, jag kan inte rekomendera Sessioner alls. Vi har slutat använda dem i vårt intranär och fått klart ökad prestanda.

 

Mvh Petter

 

Länk till kommentar
Dela på andra webbplatser

Hej Petter7!

 

Har du någon kodsnutt och resultat att dela med dig från dina tester? 20-30 samtidiga användare låter inte så mycket. Vad gjorde du för manipulering med datat i arrayerna?

 

IMO är sessioner i sig inte problemet, utan snarare vad man stoppar in...

 

/foo

 

Länk till kommentar
Dela på andra webbplatser

devilwithin

 

Det där låter inte så roligt, nej.. frågan är hur man skall göra istället? Jag använder idag vissa Session-variabler som jag tilldelar användaren när han/hon loggar in, såsom användar-id, användar-nivå (för permissions) etc, men det är bara fem olika variabler varav två innehåller strängar på max 50 tecken. Hur skall man lösa det om man inte vill använda Session-variabler, cookies är ju ett sätt men de kan ju manipuleras.

 

 

- devilwithin

---

It's not nerdy to wish for a BFG10k from the easter bunny!

 

Länk till kommentar
Dela på andra webbplatser

Kul att du svarat!

 

Javisst, jag skall förklara ungefär vad jag gjort och visa koden. Applikationen behandlar försvarsinfo så jag kan inte lämna ut några detaljer alls utan du får läsa lite mellan raderna ibland.

 

I stort sett funkar det som så att applikationen servar användare med information från ett antal DB. Det omfattar c:a 10 databaser och ett hundratal tabeller. Två värden inom databasen är mycket centrala och används överallt. Man skulle kunna kalla dem artikelnummer. "Artikelnumren" ändras sällan men används överallt i applikationen och jag ville förstås slippa hämta dessa hela tiden.

 

* Använde en sessionsArray för varje användare med artikelnummer

* Inför varje operation kollade om sessionsArrayen var tom för artikelnummer

* Om tom anropade jag en fil med Server.Execute() som gjorde följande:

=================================================

- Öppnade ett recordset.

- Slängde artikelnumren i en vektor med getRows()

- Bytte 7-bitars ASCII i alla vektor-rader mot å,ä,ö

- Slängde in vektorn i sessionsvariabeln

 

Visst blev det smidig utveckling men ack så segt. Därför gjorde jag som så att jag numera hämtar artikelnumren varje gång.

 

Tekniken föär detta är ASP med dess begränsningar.

Men jag anser nog att det hade varit bättre att använda tex RDS el annat och ladda artiklenumren på klienten. Man kunde ha tänkt sig en Terminal-server-lösning också. Då hade bara en vektor totalt behövts.

 

Här är koden om du fattar nåt av mitt slarv-programmerande :)

================================

'--för att inte kollison skall ske med anropande sidas variabler används en funktion

get_...ben()

 

function get_...ben()

 

'--Databasen ... för ...---->

%>

<!--#include file="../gemensamt/dbkoppling.asp"-->

<%

 

Dim i 'loopräknare

Dim SQL 'temphållare för SQl-strängar

Dim nisse 'av användaren vald ...

Dim arr_temp 'vektor för hämtat recordset

 

'--hämtar koder + benämning från ...

SQL = " SELECT kod, ben FROM ... "

Set rs = db.execute(SQL)

 

'--om inga poster återfinns skrivs meddelande ut och sidan avslutas

If rs.eof = True Then

Exit Function

End If

 

'--posterna läggs i array

arr_temp = rs.getrows

Set rs = nothing

Set db = nothing

 

For i = 0 To ubound(arr_temp,2)

arr_temp(1,i) = replaceSigns(arr_temp(1,i))

Next

 

'--Arrayen slängs i session-vektor

Session("arr_...ben") = arr_temp

 

End function

 

'--Byter 7-bitars ASCII mot å,äö

Function replaceSigns(str)

If vartype(str) <> vbString Then 'felhantering om tomvärde

replaceSigns = str

Exit Function

End IF

str = replace(str,"]","Å")

str = replace(str,"}","å")

str = replace(str,"[","Ä")

str = replace(str,"{","ä")

str = replace(str,"|","ö")

str = replace(str,"\","Ö")

replaceSigns = str

End Function

 

Mvh Petter

 

Länk till kommentar
Dela på andra webbplatser

Jag har funderat en stund på ditt problem igen...

Så här skulle jag göra.

 

Använd cookies och kryptera innehållet i cookierna.

Behövs mer säkerhet använd inloggning mot operativet istället.

 

Länk till kommentar
Dela på andra webbplatser

devilwithin

 

Tanken är ju visserligen god, krypteringen av cookies går ju relativt enkelt att göra. Frågan är väl hur prestandaskillnaden hämta/sätta cookies versus sessionsvariabler ser ut?

 

Inloggning mot operativet är inte att tänka på, servern ligger på webbhotell och används mot externa kunder som skall kunna skapa egna kunder som skall få tillgång till och skapa egna kunder som skall kunna.. etc etc etc.

 

 

- devilwithin

---

It's not nerdy to wish for a BFG10k from the easter bunny!

 

 

Länk till kommentar
Dela på andra webbplatser

Cookierna belastar inte minnet på servern. Som du vet så lagras ju sessionerna i minnet på servern. Jag använder en del cookies också kan jag säga inom den applikationen jag nämde och vi kan inte märka nån prestandaförsämring alls trots ganska stora värden i dem också. "stora", de är väl ungefär så stora som du vill använda :-)

 

Länk till kommentar
Dela på andra webbplatser

En fråga till...

Manipuleringen av data i arrayerna som jag visade i koden, var det det som du menade med manipulering eller menar du nåt annat? (Jag antar att du sett mitt längre svar där jag visade på ett sätt att lösa sessions-arrayer.)

 

Länk till kommentar
Dela på andra webbplatser

devilwithin

Tänkte mer på prestandan som bandbredd över nätet, mellan klienten och servern. Oavsett hur man gör så blir det en tidsförlust, även om det inte blir en minnesförlust. Vad gäller manipuleringen så menade jag att användaren kan manipulera sina cookies, och därmed eventuellt tillskansa sig information om kunder/företag som han/hon inte skall ha tillgång till. Går väl att lösa med kryptering.

 

 

- devilwithin

---

It's not nerdy to wish for a BFG10k from the easter bunny!

 

 

Länk till kommentar
Dela på andra webbplatser

Hej!

 

Petter7:

Jag har tyvärr inte tid att kika närmare på exemplet förrän imorgon, dock så har jag läst det och har lite frågor. Det vore intressant att se om man kan få bra prestanda även om man använder complexa sessionsvariabler.

Om du vill kan vi väl göra några prestandatester med olika lösningar och se om vi kan få fram skillnader?

 

Min teori är att ASP sessioner inte alls tynger ned en server, så länge man inte sparar för mycket data under längre tider där. Exempelvis arrayer med 2000 poster borde man klara även vid 30 samtidiga requests.

Dock har jag själv aldrig gjort någon sådan lösning så jag har inga empiriska belägg utan har en ren egoistisk åsikt ;)

 

devilwithin:

Jag tycker du skall köra vidare på ASP sessioner. Så länge du inte har grymt många SAMTIDIGA användare, så tror jag inte du märker någon skillnad alls!

 

Petter7:

Hur ser koden ut där du faktiskt använder innehållet i sessionsarrayen? Själva skapandet sker väl bara en gång per användare?

Hur många dimensioner har arrayen?

 

/foo

 

Länk till kommentar
Dela på andra webbplatser

devilwithin

 

Nja, har precis fått reda på att det inte var så populärt på webbhotellet att köra för mycket sessionsvariabler. De är redan måttligt förtjusta över databastrafiken (toppar på 1*10^6 träffar/dygn), så jag misstänker att det blir till att snällt sköta det med krypterade cookies istället.

 

- devilwithin

---

It's not nerdy to wish for a BFG10k from the easter bunny!

 

Länk till kommentar
Dela på andra webbplatser

Koden där jag använder session-arrayen är enkel.

 

'-Kolla om sessionen kvar

If session("var_ben") = "" Then

Server.Execute("minSidaSomFyllerArrayen")

End If

 

'-Nu använder vi arrayen

arr_temp = Session("arr_ben")

 

For i = 0 To Ubound(arr_temp,2)

'-Hämta en produkt, kolla om artikelnummer > produktnummer... bla, bla, bla

'-Fyll en hemsnickrad listbox med värden

'-.... mm mm

Next

 

Det skulle vara jättekul att prova ut lite men jag har mer än fullt upp fram till och med Juli ungefär. (Jobbar både natt och dag) så jag känner att jag inte orkar det. Däremot bistår jag gärna med genrella diskussioner som denna.

 

Här är min mail om du vill ställa direkta frågor.

petter@ivarssons.nu

Webb: www.ivarssons.nu/petter

 

Länk till kommentar
Dela på andra webbplatser

Arkiverat

Det här ämnet är nu arkiverat och är stängt för ytterligare svar.

×
×
  • Skapa nytt...