Suppose we have a website with 100k active users.
If we want to save email, name, last name and gender of users in sessions, how much space is allocated to all the sessions?
Are the sessions affecting server RAM, server bandwidth or something else?
Please give me a little information about session functionality and effect of session overload on the server.
The session themselves will consume the server RAM if your mode is set to InProc, which is limited only by the amount of RAM available to the worker process.
Considering your high demand, you want to be really careful what you're putting in the session, only when it's absolutely necessary. Don't put things in session and leave them there for use in a page or two, just go back to the database and get them, otherwise your session size will creep up drastically.
Based on what you're storing, it's only 5kb or even less, so based on 100k users, that would be:
5kb * 100,000 = 488.28MB
So you see, even though you're only storing a couple of details, at that level of usage the memory usage is quite significant.
For such high demand and usage, I would consider using a dedicated state server (StateServer mode) which allows you to manage it separately and allocate the resources to that server as required.
The other option is using SQL Server session (SQLServer mode) which is limited only by the size that is available to the database. So we're talking hard disk space here and not RAM. To be honest though, if you're going to the database to retrieve your session information, then why not just go to the database and retrieve the information you need anyway?
I would recommend you to store such data in the client when you have 100k users. Your pages will be larger and require more bandwidth but you will allocate less memory on the server.
If you talking about a ASP-application check this article http://www.codeproject.com/Articles/416137/Understanding-Session-Management-Techniques-in-ASP
NOTE:
This answer was posted when the OP asked about php and asp.net
Are the sessions affecting server RAM, server bandwidth or something
else?
Sessions are affecting server RAM
Please give me a little information about session functionality and
effect of session overload on the server.
If the effect of sessions overload the server, the server will run slow because of the usage of the RAM.
Most of the settings of sessions can be changed in the php.ini file
If you want to know more about session functionality, you should check out the pages about sessions on php.net or even the wiki.
There is too much information about sessions to actually post in an answer.
Related
How much space IIS 6 and 7 appropriate to any asp.net application for sessions?
have this space limitation?
thanks
AFAIK, In-Process Mode is limited only by the RAM available on the server. Do you have specific concerns that you might exceed available RAM? If so, either increase your RAM or use an alternative session state mode:
http://msdn.microsoft.com/en-us/library/ms178586.aspx
There are so called sessionstateprovider. So you can actually choose. The ones I'm aware of are:
In memory
Session state service
SQL server
Velocity
Velocity is a distributed caching that can be used as session state container. I think it's now called or part of AppFabric.
The size of a session depends on your app. There is no real hard limit I know of. The best thing is to keep it as small as possible, but again, even large sessions could be required and if planned for are probably no problem.
On the website I am developing, I have a number of "user preferences" that I keep stored for my returning, registered users (for example, the number of product summaries per page to display). I am curious if there is any performance benefit to storing/retrieving this data in an ASP.Net SQLServer Session State versus retrieving it as-needed directly from my database. Many thanks in advance!
Its always better to store Data in Session State (performance point of view), as long as the data isn't too Huge. This way, you Production Data Database (where you persist your UserData) Hits would reduced. Just make sure that User Wouln't change his preferences which are cached in session.
Only potential problem with session is that Session is maintained per User. so, if there are too many users on your website, session state grows but since you are using SQL Server as you Session Store, you are good on that. Had you been using InProc SessionMode, your Session would have been in memory (a critical resource on production servers!)
You are taking the hit going to sql server anyways. So you shouldn't have a noticeable performance impact and also if using sql server for session state - you don't have to worry much about the implementation details - hence could be a 'bit' easier to use. But no - there is no main benefit. one could argue it depends on how you store/lookup your information but for most apps the difference here is absolutely negligible - it's up to you how you want to implement. Now if you ever move away from sql server session state then you have another set of issues to be concerned over (app resets, etc) but thats not in the scope of what you asked : )
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.
One of my applications uses sql session state, the timeout is currently set to 20 minutes. My question is, since this is stored in the database and not in server memory, I should be able to increase the timeout without any significant performance issues right?
I don't really understand the importance of the timeout for the database session state scenario, since the database should easily be able to handle a lot of sessions.
I think the timeout's relevance is more for public-facing websites where you could potentially get a lot of hits and fill up your database fairly quickly. That being said, infinite isn't exactly what you want either...
I was looking for confirmation of your opinion, too-- that if harddrive space is cheap, I should be able to have 8 hour sessions in SqlSessionState without noticable performance issues (beyond what 20 minute sql server session cause), given a medium sized office level intranet application.
Just try to keep in mind that the advice about session deals with how many users you can deal with at once, how likely it is that users will start some work, get interrupted for a long time, and need to continue.
And finally if you are storing authentication tokens or roles in session, then you may want to expire those more often to check the user still is a user and still has those roles.
Length of a session should be determined by the functionality (e.g. on-line banking would tend to shorter timeout, while a site like SO instead allows longer period to type up an entry), not by the implementation mechanism.
Using out-of-process mode allows retaining session context in case of IIS re-cycles, and requires less direct (used by IIS itself) memory resources. But that has no relation to whether a session should last 8 hours or 5 min.
I recently came across a ASP 1.1 web application that put a whole heap of stuff in the session variable - including all the DB data objects and even the DB connection object. It ends up being huge. When the web session times out (four hours after the user has finished using the application) sometimes their database transactions get rolled back. I'm assuming this is because the DB connection is not being closed properly when IIS kills the session.
Anyway, my question is what should be in the session variable? Clearly some things need to be in there. The user selects which plan they want to edit on the main screen, so the plan id goes into the session variable. Is it better to try and reduce the load on the DB by storing all the details about the user (and their manager etc.) and the plan they are editing in the session variable or should I try to minimise the stuff in the session variable and query the DB for everything I need in the Page_Load event?
This is pretty hard to answer because it's so application-specific, but here are a few guidelines I use:
Put as little as possible in the session.
User-specific selections that should only last during a given visit are a good choice
often, variables that need to be accessible to multiple pages throughout the user's visit to your site (to avoid passing them from page to page) are also good to put in the session.
From what little you've said about your application, I'd probably select your data from the db and try to find ways to minimize the impact of those queries instead of loading down the session.
Do not put database connection information in the session.
As far as caching, I'd avoid using the session for caching if possible -- you'll run into issues where someone else changes the data a user is using, plus you can't share the cached data between users. Use the ASP.NET Cache, or some other caching utility (like Memcached or Velocity).
As far as what should go in the session, anything that applies to all browser windows a user has open to your site (login, security settings, etc.) should be in the session. Things like what object is being viewed/edited should really be GET/POST variables passed around between the screens so a user can use multiple browser windows to work with your application (unless you'd like to prevent that).
DO NOT put UI objects in session.
beyond that, i'd say it varies. too much in session can slow you down if you aren't using the in process session because you are going to be serializing a lot + the speed of the provider. Cache and Session should be used sparingly and carefully. Don't just put in session because you can or is convenient. Sit down and analyze if it makes sense.
Ideally, the session in ASP should store the least amount of data that you can get away with. Storing a reference to any object that is holding system resources open (particularly a database connection) is a definite scalability killer. Also, storing uncommitted data in a session variable is just a bad idea in most cases. Overall it sounds like the current implementation is abusively using session objects to try and simulate a stateful application in a supposedly stateless environment.
Although it is much maligned, the ASP.NET model of managing state automatically through hidden fields should really eliminate the majority of the need to keep anything in session variables.
My rule of thumb is that the more scalable (in terms of users/hits) that the app needs to be, the less you can get away with using session state. There is, however, a trade-off. For web applications where the user is repeatedly accessing the same data and typically has a fairly long session per use of the site, some caching (if necessary in session objects) can actually help scalability by reducing the load on the DB server. The idea here is that it is much cheaper and less complex to farm the presentation layer than the back-end DB. Of course, with all things, this advice should be taken in moderation and doesn't apply in all situations, but for a fairly simple in-house CRUD app, it should serve you well.
A very similar question was asked regarding PHP sessions earlier. Basically, Sessions are a great place to store user-specific data that you need to access across several page loads. Sessions are NOT a great place to store database connection references; you'd be better to use some sort of connection pooling software or open/close your connection on each page load. As far as caching data in the session, this depends on how session data is being stored, how much security you need, and whether or not the data is specific to the user. A better bet would be to use something else for caching data.
storing navigation cues in sessions is tricky. The same user can have multiple windows open and then changes get propagated in a confusing manner. DB connections should definitely not be stored. ASP.NET maintains the connection pool for you, no need to resort to your own sorcery. If you need to cache stuff for short periods and the data set size is relatively small, look into ViewState as a possible option (at the cost of loading more bulk onto the page size)
A: Data that is only relative to one user. IE: a username, a user ID. At most an object representing a user. Sometimes URL-relative data (like where to take somebody) or an error message stack are useful to push into the session.
If you want to share stuff potentially between different users, use the Application store or the Cache. They're far superior.
Stephen,
Do you work for a company that starts with "I", that has a website that starts with "BC"? That sounds exactly like what I did when I first started developing in .net (and was young and stupid) -- I crammed everything I could think of in session and application. Needless to say, that was double-plus ungood.
In general, eschew session as much as possible. Certainly, non-serializable objects shouldn't be stored there (database connections and such), but even big, serializable objects shouldn't be either. You just don't want the overhead.
I would always keep very little information in session. Sessions use server memory resources which is expensive. Saving too many values in session increases the load on server and eventualy the performance of the site will go down. When you use load balance servers, usage of session can run into problems. So what I do is use minimal or no sessions, use cookies if the information is not very critical, use hidden fields more and database sessions.