ASP.net session state
Discussion
Currently working on a project that includes a couple of forms that may take end users (who must be logged on) quite a long time to complete. The catch is that their session may timeout if they take too long entering stuff into the form without saving. The customer is asking if we can increase the timeout from 20 to 60 minutes, but I'm not sure that's a good idea because
a) When the site takes off we could have several hundred people online at any moment
b) From my googling, I was able to glean the the .net session state is unreliable beyond 20 mins.
We are only explicitly storing a few short strings (prolly 100 bytes tops) per logged on user so even if there were 2000 sessions in memory that would only be ~200Kb of server memory used for session state, which sounds OK to me. Or is there a much larger impact for every session that a webserver creates?
Does anybody have any experience or thoughts on this? Any stats to show impact on server performance?
Cheers!
a) When the site takes off we could have several hundred people online at any moment
b) From my googling, I was able to glean the the .net session state is unreliable beyond 20 mins.
We are only explicitly storing a few short strings (prolly 100 bytes tops) per logged on user so even if there were 2000 sessions in memory that would only be ~200Kb of server memory used for session state, which sounds OK to me. Or is there a much larger impact for every session that a webserver creates?
Does anybody have any experience or thoughts on this? Any stats to show impact on server performance?
Cheers!
Bonce,
The options to preserve session state in ASP.NET are much more flexible than classic ASP.
You could use SQL Server or even an out of process dedicated state server to avoid issues when your site moves to a clustered web server environment.
It sounds though as if you could simply use the HttpContext.Items collection, which doesn't carry a memory or database overhead (in case you use SqlServer state) on the server. The only thing you then need to do is to use Server.Transfer to send the user to a different page, where you request the HttpContext Items again.
Here's an example:
// Page 1
private void Page_Load(object sender, System.EventArgs e)
{
ArrayList list = new ArrayList();
list.Add("string 1");
list.Add("something else");
this.Context.Items["list"] = list;
// make sure to use Server.Transfer to preserve the context collection
Server.Transfer("webform2.aspx");
}
And then in page 2
private void Page_Load(object sender, System.EventArgs e)
{
ArrayList list = this.Context.Items["list"] as ArrayList;
// do something with the collection, or add more items, and Transfer to another page again.
if(list!=null)
{
foreach(string s in list)
{
// do something
}
}
}
Hope that makes sense.
Just shout in case you got any queries.
Cheers,
Wim
P.S. Sorry about the lack of indentation - the PH forums aren't made to display code blocks!
>> Edited by wimdows on Monday 2nd August 16:55
The options to preserve session state in ASP.NET are much more flexible than classic ASP.
You could use SQL Server or even an out of process dedicated state server to avoid issues when your site moves to a clustered web server environment.
It sounds though as if you could simply use the HttpContext.Items collection, which doesn't carry a memory or database overhead (in case you use SqlServer state) on the server. The only thing you then need to do is to use Server.Transfer to send the user to a different page, where you request the HttpContext Items again.
Here's an example:
// Page 1
private void Page_Load(object sender, System.EventArgs e)
{
ArrayList list = new ArrayList();
list.Add("string 1");
list.Add("something else");
this.Context.Items["list"] = list;
// make sure to use Server.Transfer to preserve the context collection
Server.Transfer("webform2.aspx");
}
And then in page 2
private void Page_Load(object sender, System.EventArgs e)
{
ArrayList list = this.Context.Items["list"] as ArrayList;
// do something with the collection, or add more items, and Transfer to another page again.
if(list!=null)
{
foreach(string s in list)
{
// do something
}
}
}
Hope that makes sense.
Just shout in case you got any queries.
Cheers,
Wim
P.S. Sorry about the lack of indentation - the PH forums aren't made to display code blocks!
>> Edited by wimdows on Monday 2nd August 16:55
Nice idea but we can't use server.transfer for the hundreds of hyperlinks dotted around the site!
Besides, the site is written and working, I was just wondering if anyone had any stats on session timouts vs performance. We use session variables on the majority of our websites and have done for years to no ill effects.
Besides, the site is written and working, I was just wondering if anyone had any stats on session timouts vs performance. We use session variables on the majority of our websites and have done for years to no ill effects.
From what I remember, the basic footprint required for a session is around 10KB, whether you store something or not. If you have 200 concurrent users you may be loading the server with 2MB rather than 200KB.
There's nothing wrong with using Session - there are plenty of sites using it. It's just that some sites grow beyond their initial estimates and then you run into problems. That's why it's preferable to redegin a stateless site.
The real problems arise persisting non thread safe objects in the Session variables and causing thread contention and deadlocks which will affect the sites scalability.
It's difficult to tell - best bet is to monitor server performance - I think there may be performance issues later - I've never designed an application using Session with that many concurrent users!
There's nothing wrong with using Session - there are plenty of sites using it. It's just that some sites grow beyond their initial estimates and then you run into problems. That's why it's preferable to redegin a stateless site.
The real problems arise persisting non thread safe objects in the Session variables and causing thread contention and deadlocks which will affect the sites scalability.
It's difficult to tell - best bet is to monitor server performance - I think there may be performance issues later - I've never designed an application using Session with that many concurrent users!
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff