i want to know where a session is stored when i set it in asp.net application. Does it consume RAM or hard disk space?
Actually, i save a datatable into a session variable. I save it into session because calculation of the datatable takes long time. In order not to calculate the datatable again, i get it from the session.
But i am curious about the time when the datatable will grow much larger than now. Will it stuck the ISS?
Thanks
Session state in ASP.NET is by default stored in process memory (which is RAM).
You can change this in web.config by altering the values of the configuration/system.web/sessionState element:
<configuration>
<system.web>
<sessionState mode="...">
</system.web>
</configuration>
The available options are:
InProc (default)
StateServer - will store in a seperate process which can be on a seperate computer
Off
SqlServer - will store state information in a sql server database
Custom - allows you to provide your own session store
Depending on how you configure the Session in your Web.Config, the Session can be stored In-Memory, Asp.NET State Server, Sql Server.
By default, the session is stored in-memory, which means the Ram. If the data-table gets large and there are a number of concurrent users, you may get an exception. Depends on how many users are accessing the system concurrently, what is the Ram on your system etc.
Session state can be stored in different places that you can choose. Here's a good explanation on MSDN
The default is in memory on the server where you web application runs, so if your session grows too large you will indeed have ram/paging problems.
But why session? Is the data in the datatable user-specific? Otherwise Cache would be more appropriate.
If you are using InProc session, then it will be stored in memory. So if you have enough memory it will be in memory. Once you hit your limit look forward to it paging out to disk.
You can also use out of process session storage like the SQL server. This is configurable in the web.config. Note that you will need to have a database configured for it. You can also check out MSDN to read up on the storage types.
Old link above, but still partially useful. Another quick look and I'm found a better link that goes more into detail.
The typical InProc session state is stored in memory of the web server.
Related
We're currently building an application in which we rely heavily in storing data in sessions for each individual user. We cannot use Cache since these data are specific to users, and re-querying data when we need it is an expensive process: so the solution was to query once from the DB, store into session, and then keep using it until the session ends. A concern I have is how IIS handles these sessions when too much session data is stored in memory.
when does it know when to clear session data?
how does it determine which session variable to clear out first if memory runs low?
Is there a way to set priories to individual session objects: clear less prioritized data first.
What you're doing is using InProc sessions whereby the sessions are stored in the memory of the current worker process.
when does it know when to clear session data?
InProc sessions are cleared as you might expect when zero requests have been made for the session for the length of the configured session timeout.
<sessionState mode="InProc" timeout="30"/>
However this is not an exact duration. The session will be cleared after the timeout but only when a cleanup is triggered by the internal mechanics of the session handler. Each session doesn't have it's own timer polling for a session timeout. It will get done, when it's optimal for it to be done.
You should also note that since worker processes are regularly recycled any and all sessions stored in that process will be deleted. InProc sessions will also not work in web farms since each request could be handled by a different machine.
how does it determine which session variable to clear out first if memory runs low?
It doesn't. It will simply shift to using virtual memory like any other windows process and as such you would now be backing your sessions with disk based virtual memory instead of chip based memory. Eventually the whole process would get recycled and everything would be wiped as per 1.
Is there a way to set priories to individual session objects: clear less prioritized data first
Not out of the box with InProc. Ultimately the session is just storing objects so you could run your own cleanup according to whatever makes sense for your app by simply tagging your InProc objects with some kind of value. But you'll quickly end up simply replicating the features already available and probably not doing it as well as MS.
Check out System.Web.SessionState namespace for some options but bear in mind that by using InProc you are always going to be held to ransom by worker process recycling which can be triggered by many different things: antivirus software resetting the timestamps on web.config files for example.
For a viable and popular alternative to InProc sessions, check out Redis.
I deployed an ASP.net web site to two servers and put them behind the load balanced environment. Now that problem is that the performance is really slow. Even for just simple button event, it takes long time to finish the simple button event. However, if I access the site separately (by its server’s address), performance is good. What our system engineer told me was that the application handles session state in process as if it runs on only one server, it could not handle clustering. So, he suggested that I should use the session object in the code to store the session in SQL server, or cookie.
I am currently using session variables to store the session.
I am kind of a new to ASP.net and I am not sure exactly what this mean and how I can accomplish this in my .net code (C#)?
Thanks.
Here is a good link to start you off: ASP.NET Session State
You would probably want to go with the Out of process mode where the servers all access 1 session process on a designated server, if speed is your top priority or SQL Server mode where all servers access 1 database if reliability is your top priority as with out of process mode if the process dies your session data is lost similar to how in-process session handling works.
No coding changes for storing session data would be needed, just the initial configuration of the environment and a web.config change.
First off, you need to configure sessionstate in your web.config for what you want to do. Here is a step by step tutorial on storing sessionstate in sql server. Hope it helps!
http://support.microsoft.com/kb/317604
I've read several threads about this topic and need some clarification on a few sentences I read in a book:
If you store your Session state in-process, your application is not scalable. The reason for this is that the Session object is stored on one particular server. Therefore storing Session state in-process will not work with a web farm.
What does "scalable" in the first sentence mean?
Does the third sentence means if my app resides on a shared web host, I shouldn't use Session["myData"] to store my stuff? If so, what should I use?
Thanks.
1:
Scalability in this sense:
the ability of a system, network, or process, to handle growing amounts of work in a graceful manner or its ability to be enlarged to accommodate that growth.[
2:
Use a session server or store sessions in SQL Server, which are described here.
ASP.NET can store all the combined Session information for an Application (the "Session State") in 3 possible places on the server-side (client cookies is also possible but that is a different story):
"InProc" (In Process) which means in memory on the IIS server attached to the asp.net worker process,
"StateServer" which is a separate process that can be accessed by multiple IIS servers but still stores the Session state in memory, and
"SQLServer" which stores the Session state in a SQL Server database.
1) The reason In-process is not scalable is if your needs exceed the capacity of a single IIS server, multiple servers can't use an In-process session state. If you have determined a shared hosting scenario will fulfill you needs, you don't need to worry about it.
2) When you store something in Session["Name"], ASP.net stores that data wherever the application is configured to store Session state. If you want to change where Session state is stored, all you need to do is configure your web.config file. If you are using a shared hosting environment, your IIS deployment is considered single server even though no doubt the actual servers are in a farm of some sort.
See: MSDN Session-State Modes
I keep hearing that it's bad practise to store large object collections / anything in the session. Often during conversation it's quickly followed by: 'Just turn sessions off'
So what is the general problem with sessions? I use them a fair bit and since they 'real' session is stored behind a strongly typed container I don't really see the issue.
There is nothing wrong with session - you just need to be mindful of its limitations. To say "just turn off session" is throwing the baby out with the bathwater.
There is a huge difference between storing BIG objects and small objects in a session
The session will stay alive on a server untill it expiers, and that means those big objects pollute your available memory. If you do that with a server under load, or a server that runs many application pools, then this can cause trouble.
You dont need cookies to have a session, since ASP cal also encode that information in the urls. Also you can configure the session store to run out of process, or even to store the information inside a SQL Server (reducing the memory load on the server, and enabeling sessions across a farm)
So basically: Objects are ok - Big objects not
Here's my take -- sessions are not bad but sometimes they are overused. It can also be harder to understand a web application's flow when it relies on a lot of sessions so of course you should be careful not to get carried away.
However, you should feel free to use them anytime you need to store temporary data to be made accessible across multiple pages. In no other situation should they be used. But that situation is one for which sessions were specifically designed.
Now, if you're worried about memory consumption on the server, that's not necessarily a reason to avoid sessions. But it may be more of a reason to avoid the InProc session provider. In fact I'm not a fan of InProc sessions as they tend to expire prematurely after a certain number of recompiles in your application.
What I actually prefer and nearly always use are SQL Server sessions. They'll be slightly slower, but the benefits are numerous. They'll persist even if the server is rebooted and that makes them a very reliable choice. And of course since they're stored in the SQL file system instead of in memory, they won't make such a big hit on memory.
This article on MSDN talks about the various session providers and also explains how to configure SQL to handle your sessions. If you don't have SQL, just know that even the free SQL Server Express 2008 can be configured as your session provider.
I had thought that it largely depends on the traffic to your web site. If you are running something like amazon.com, trying to store the user's shopping cart in a session would take huge amounts of IIS allocated memory, bringing down your web server. For smaller web sites, session variables are fine to use in moderation.
Storing large objects in Session is bad, yes, but "large" is relative.
Basically, storing an object in session will keep it in memory until the session expires, so if you have a site with a high user count all storing mega-objects in their session, you'll kill your server pretty quickly.
With that being said, an argument could be made for the idea that if you have objects that are 5k+ in memory and have enough users to actually cap out a server then you can probably afford more hardware anyway.
There are also topics like server clustering and session integrity between boxes in the cluster. Some frameworks handle this, I don't know if .NET does or not.
There are two things to be careful of:
Memory consumption: if you store large data objects in session and you have many user you may well run out of memory or at the very least triggering many early recycling of your application
This is only a problem if you have multiple web servers (web farm): the session has to be stored externally (not in process) in a SQL server or a windows service so that it is accessible from different machines. This can be quite slow at times.
Session requires the user to have cookies turned on
If you're working in a web farm, you'll run into trouble.
I guess these reasons don't have anything to do with storing large objects in session, just in using sessions at all.
2 major issues come to mind...
1) Persistence of sessions across servers when you start scaling your website
2) Memory usage explosion from storing UI objects in session state
The more serious issue is the tendency to store objects in session. When you store something as innocuous as a Label from a page on your page, you get LOTS of unwanted object attributes as well. You probably just wanted the text of that label stored in your session, but along with it, you get references to the page itself...and all of a sudden, you have a massive usage of memory to store the page, its view state, and lots of unwanted attributes in memory on your server.
Check out this link about storing UI elements in session
You may want to check out this question as well.
This is an old thread although.
But I have an experience for a session problem. I would like to share it.
There is a simple flow.
One .aspx validate a client, and read a bill-html from a file (for this client), then save this html(about 2MB) in a session variable.
This .aspx will auto redirect to next .aspx, the next .aspx retrieves this html from session. Then show it to the client.
It works fine in most cases. But some clients encountered a problem: The bill he saw is not his bill, but others.
We used sniffers tools to intercept the network package.
And we saw a strange situation:
Our IIS has definitely sent the SessionID(eg: 1111111) to the client, But when the client redirects to next page and tries to access session. The SessionID(eg: 11112222) that this client brings is different.
We think that the browser of that client does not accept the SessionID.
And finally, we abandon the use of Session, and solved this problem.
How Can I persist a User-Specific data for an ASP.Net application.
I tried Session Variable - Not good when the worker process recycles.
I need something that can be accessed GLOBALLY by any class of my application.
Advice most welcome.
I tried to utilize asp.net session State Server but I got some DLLs crashing because they are Unserializable.
Is there any other way to have a persistent variable across the application?
ASP.NET session state can be configured to persist to a database.
Here is a tutorial on how to set that up.
Store Data in a Database (such as SQL Server).
You should use Session. You can access session state globally in a class like this...
HttpContext.Current.Session
To avoid losing sessions by the worker process recycling, use StateServer mode.
You can change the Session State Server to not be in process which will make it far more stable and also seperate it from the worker process (You'll need to be able to start the Asp.NET State Service on the server if it's not already running)
<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20"/>
Also if you need to share it across applications in the same domain you should be able to give them the same machine key
Theres nothing you can really do about the process recycling. If you use the Cache smartly to retain information in a more global sense but you still have the same worker process limitation.
I try and design my app in a n-tier setup with business entity objects. The factory methods for my objects use the cache kind of like a lazy instantation pattern. If its in the cahce, pull it. If not, put it into the cache for next time.
i.e
MyAppsNameSpace.MyBusinessLayerNameSpace.MyObject.GetObject(objectID)
now when this returns my object, it may be from the cache or may not, if the object is under high usage then it will be probably be cached.
This can be used throughout your entire app and because the caching mechanism is maintained centrally you dont really have to worry about it.
You could use the Profile Provider with a SQL database as your backing store.
See this MSDN Article
If you lose data when the worker process recycles then you should stop using the InProc persistance mode for the Session. Use StateServer or SQL Server. Ultimately you could build your own session persistance module if neither satisfies you.