Welcome to HostingForumz.com!
FAQFAQ      ProfileProfile    Private MessagesPrivate Messages   Log inLog in

Asp| Cookies vs Session Variables

 
   Web Hosting Problem Solving Community! (Home) -> IIS RSS
Next:  IIS6,asp.neret,sqlserver2000  
Author Message
anonymous1310

External


Since: Feb 29, 2004
Posts: 12



(Msg. 1) Posted: Wed Mar 31, 2004 4:06 am
Post subject: Asp| Cookies vs Session Variables
Archived from groups: microsoft>public>inetserver>iis (more info?)

Howdy ...

I am wanting to maintain session state for an intranet application but the session timeout is becoming a problem, due to the need to spend quite a long time in filling in individual forms. I have currently set the session timeout to 30 minutes but this is not the ideal situation due to the overhead on the server.

The alternative, I believe is to store the info. in cookies rather than session variables. I sort of figured "in-memory" cookies may be the way to go ('cos I do not want to write the data to disk).

Will the load on the server be reduced if I were to use 'in-memory' cookies instead of session variables?
I undestand that cookies are stored on the local pc, but if I do not specify an expiry date which causes it to become an 'in memory' cookie, who bears the memory cost, the server or the user Pc?

Thanks in advance.....

 >> Stay informed about: Asp| Cookies vs Session Variables 
Back to top
Login to vote
kenremove

External


Since: Aug 23, 2003
Posts: 3041



(Msg. 2) Posted: Wed Mar 31, 2004 10:28 pm
Post subject: Re: Asp| Cookies vs Session Variables [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

An in-memory cookie is stored in the client's memory. However the entire
cookie is transmitted between the browser and server for every request and
response (with the session variables, only the ASPSessionID is transmitted
in the cookie). So, if you store 30kb of stuff in there, it'll be quite
slow! Additionally, unless you use some kind of encyption mechanism, the
cookie's contents will be in plaintext, and can be altered by a malicious
user (either the end user, or a man-in-the-middle).

Session variables themselves aren't a particular burden on a server. Suppose
you have 1,000 active sessions, and you store a couple of hundred bytes for
each user - how much server memory is that? Not a great deal. Managing the
sessions consumes a few more MB, but that's about it. More worrying is the
fact that it's not easy to get "out" of an application that designed to use
in-memory ASP session variables (.e.g you can't port half the app to ASP.Net
or something, it'll all-or-nothing).

Cheers
Ken

"Ricardo" <anonymous RemoveThis @discussions.microsoft.com> wrote in message
news:78D28C7C-F02C-4BAD-B3E1-7E6CE32B4788@microsoft.com...
: Howdy ...
:
: I am wanting to maintain session state for an intranet application but the
session timeout is becoming a problem, due to the need to spend quite a long
time in filling in individual forms. I have currently set the session
timeout to 30 minutes but this is not the ideal situation due to the
overhead on the server.
:
: The alternative, I believe is to store the info. in cookies rather than
session variables. I sort of figured "in-memory" cookies may be the way to
go ('cos I do not want to write the data to disk).
:
: Will the load on the server be reduced if I were to use 'in-memory'
cookies instead of session variables?
: I undestand that cookies are stored on the local pc, but if I do not
specify an expiry date which causes it to become an 'in memory' cookie, who
bears the memory cost, the server or the user Pc?
:
: Thanks in advance.....

 >> Stay informed about: Asp| Cookies vs Session Variables 
Back to top
Login to vote
Display posts from previous:   
   Web Hosting Problem Solving Community! (Home) -> IIS All times are: Pacific Time (US & Canada) (change)
Page 1 of 1

 
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum



[ Contact us | Terms of Service/Privacy Policy ]