We're using an out-of-proc session state service/ASP.Net Session state. We know were having problems with this as it's been abused in the past, too much stored in session state too often, so were in the process of moving onto a more scalable system.
In the meantime, though, we're trying to get our heads around how a session state service manages it's memory and what limits do we have. But none of the Microsoft docs seem to go into any details.
Specifically I want to know:
What are the limits to how much "the standard" out of proc session state service (installed along with IIS in the windows management console) can store?
(x64)
Is there a per user limit?
by standard service, I mean this one:
There is no limit beyond that of the machine hosting the service. If it has 16 gigs of RAM, assuming a few gigs are used for other processes / the OS / etc., there would be something like 13 GB of memory available for the session data. The data is not persisted to disk so the data only ever exists in RAM / memory; this is why when you restart the service all sessions are gone. The memory is volatile and works like a RAM disk.
If you're reaching the memory limits of the machine hosting your session state service, you are either storing too much data per user, or have too many users storing a little data. You're already on the right track as the next step is moving to a distributed session state provider to scale correctly. This is often achieved via a distributed caching system which comes with a session state provider, or by writing your own provider against said system.
There is no per-user limit on data, but note that out of process communication always happens via serialization. Therefore, there is a practical limit as serializing/deserializing a gig of user data per request is going to be very slow no matter how you approach it.
Related
I have a memory-intensive C# app that resides on the same server as SQL Server.
I have tweaks in my application to limit in-memory caching and I am aware of how to set (and have set) maximum memory limits on my SQL Server.
PROBLEM: When the C# app wants to use more memory than is available due to SQL Server's caching, my app slows greatly, presumably to venturing into Virtual Memory space. I can prevent this most of the time by eyeballing how much RAM is available and setting the appropriate values in my custom C# code (whether to cache to RAM and/or to SQL Server) and in SQL Server's settings.
HOWEVER: Sometimes the machine's memory usage goes beyond my eyeballed boundaries due to other processes on the machine, typical OS needs fluctuating, etc.
I have noticed that SQL Server will often yield RAM to other processes, such as Chrome, MS Word... it doesn't seem to do so for my process. I have a gut feeling that my C# app isn't actively using all of the cached data in SQL Server...
So, how do I detect when SQL Server won't yield the RAM to my application and/or how do I detect when my application cannot allocate additional bytes of physical RAM?
In asp.net, the default session time out is 20 minutes. Suppose if i am changing the session time out period to 2 hours or greater than of its, then will it cause any performance issue on server side?
I would like to know Is there any limitations or disadvantages of using maximum session out time in asp.net?
Please guide me to get out of this issue?
Sessions are maintained on server for each user. Increase in session time out will prevent the Server from releasing memory allocated to inactive session.
I would like to know Is there any limitations or disadvantages of
using maximum session out time in asp.net?
HttpSessionState.Timeout Property
The Timeout property cannot be set to a value greater than 525,600
minutes (1 year). The default value is 20 minutes.
Disadvantage:
You will have performance issues if you have large number of users and with increase in session timeout, your inactive sessions will remain in Web server memory which may cause application pool to recycle, which would result in loosing all sessions for all users.
If you are you using IIS6 or greater then depending on your Application Pool settings it may affect how frequently the w3wp process is recycled. When the app pool is recycled your sessions will be lost unless you use out-of-process session state management or sql as a session state host.
If you increase the timeout to two hours individual users wont lose their session as often, but it increases the odds that all users browsing the site will occasionally get logged off when the process is recycled.
Increasing the session time means that a web page left idle is less likely to time out (such as if the user goes to lunch leaving the web page open). However, this takes up more server resources, since, as Habib says, the server must store the user information during this time.
It can also be is a security risk. If the user closes the web page rather than logs out, it increases the window for a CSRF attack.
The best thing to do is understand how your users use the web page. If pages must be kept open for long periods, look at a periodic callback or refresh for the page. Alternatively, if the site is security sensitive, consider logging the user out automatically after a period of inactivity.
Take in consideration that if your trying to raise the timeout value in a shared hosting environment you will fail as they block you from this by set that value in the machine.config file and hat takes precedent, you will need to use SQL Session 's for that and you will be free to change that timeout time as you please.
They also normally restart the AppPool every often to unblock any malicious or bad code that could block other websites, and every time the AppPool restart, here goes all your sessions (not if you use SQL Sessions instead, of course)...
In the other hand, if your hosting the web application yourself, aside of the size in memory (remember that Im assuming that you are saying user sessions and as the name says, are per user, per application you would use Application Sessions). If you consider this memory increase, nothing, not even performance would be diminish.
I have a static class with a static dictionary to keep track of some stats. Is this approach viable in a single and multi server environment?
Not in a multi-server environment. Unless the dictionary isn't the .Net dictionary, but one that works against a database or some other outside storage. Also in a single server environment you should remember the Dictionary will be emptied with every IIS refresh.
No, a static variable in memory in one server won't be visible or synchronized with other servers.
Since you mention "keeping track of stats", what many multi-instance server farms end up doing is post-processing locally gathered data into an aggregate view of activity across all the servers. Each server accumulates stats in memory for a short while (a few minutes), then writes the data from memory to a log file on the local file system. Every few hours or daily a batch process copies the log files from each server in the farm to a central location and merges all the log records together to form one collection of data. One useful byproduct of this might be consolidating user activity across multiple servers if a user's web requests were served by different servers in the same farm (load balancing).
Depending on the volume of data, this batch processing of log data may itself require quite a bit of computational power, with multiple machines crunching different subsets of the server logs, and then those intermediates getting reduced again.
Google Sawzall is an example of a very large scale distributed data processing system. I believe Sawzall is (or was) used at Google to process server access logs to detect fraudulent ad click patterns.
No, it's not viable in a web farm multi-server environment.
Storing Session State in an ASP.Net Web Farm
Allowing Session in a Web Farm? Is StateServer Good Enough?
Fast, Scalable, and Secure Session State Management for Your Web Applications
ASP.NET Session State
Session-State Modes
The State Mode options are:
InProc mode, which stores session state in memory on the Web server. This is the default.
StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
Custom mode, which enables you to specify a custom storage provider.
Off (disables session state)
Normally, this is what you would use Application state for.
We have WPF client that communicate with the server by web-service.
In the thick installation both client + server + sqlserver are installed on the same machine. The machine has 500M RAM.
I will be great full for tips about:
its very difficult to find the bottleneck , because you can use in profiler on such machine without heavy impact on the result. the profiler can cause to page faults due to missing memory and the diagnostic will show irrelevant results.
In the task manger i see that the asp process consume 135M this is too much. I tried to understand why it consume so much and i saw area - undefined. is it the asp process itself? does asp process has a big memory overhead? in this architecture (thick) i don't have multiple clients against the server . do you have any memory advice for it?
the benchmark results has big variety . i think it because page fault. do you have any advice?
Thank you very much. i am from java world , so i am new to it.
Download the process explorer and see whats needs the memory. Also check with starts with your server using the autoruns
Now 500M is little memory for a server.
From my experiences the SQL server needs a memory, iis and asp.net needs also memory, but the SQL need more, especial for cache and be fast, and make the indexing and all that. The asp.net is running with out needs of too much memory, but all depends from how you have setup your system, how many pools you have give to asp.net (I believe only one with 500M), how man sites, how many memory you get with your sites and so on.
More about
If its possible, move the SQL to a better server, and all the rest computers connect to this one. The SQL server needs memory.
Second possible, move the sap.net session from memory to sql server.
Limiting the memory use of iis can be done by:
Go to the IIS MMC
-> click Application Pools
-> Right-click the pool
-> select Advanced Settings
-> go to the Recycling section, you will see there are two settings:
Private Memory Limit (KB) Virtual
Memory Limit (KB)
When any of these 2 settings are set, if the worker process exceeds the
private or virtual memory quota, IIS will recycle that pool which limits
the memory usage.
You can limit the SQL server memory use in the SQL MMC, go to the database servers properties
Overall I would recommend to split the database and the iis server. 0.5gb is not a lot of memory for a server.
For some reason, the session is abandoning unexpectantly, and wreaking havoc in our application. We've had the app setup to use Session and have been using it for several months with no problems. Now, as we add additional content and store additional info in it, the Session is dumping well before the 20 minute timeout than its supposed to. I'm at a loss for the reason why... could it be because we may be adding a lot of data in the Session (not sure of exact size)? This is my local machine after all (Win 7, using IIS, ASP.NET 4.0, 4 GB RAM).
Or could there be other reasons for this occurrence? Any thoughts?
Thanks.
ASP.Net sessions are stored in the cache. If you are running out of memory then it will be dumped. You need to store the session in a database or other storage to keep it. I'll try to find a relevant link. Sessions are not meant to store tons of data!
Here is a link explaining how to use out-of-process sessions. Basically the idea is that, by default, ASP.Net/IIS will use in-process sessions (which are fastest) but are also limited by the power/storage on the server running IIS. The alternatives are to use a session state farm or a SQL server to store sessions. These are a bit slower but offer more flexibility. You will need to take into account the ability to serialize sessions into your decision.
Here is an excerpt from a book I've been reading (Programming Microsoft ASP.NET 3.5 by Dino Esposito):
Why Does My Session State Sometimes Get Lost?
When the working mode is InProc, the session state is mapped in the memory space of the AppDomain in which the page request is being served. In light of this, the session state is subject to process recycling and AppDomain restarts. As we discussed in Chapter 2, the ASP.NET worker process is periodically restarted to maintain an average good performance; when this happens, the session state is lost. Process recycling depends on the percentage of memory consumption and maybe the number of requests served. Although the process is cyclic, no general consideration can be made regarding the interval of the cycle. Be aware of this when designing your session-based, in-process application. As a general rule, bear in mind that the session state might not be there when you try to access it. Use exception handling or recovery techniques as appropriate for your application.
In Knowledge Base article Q316148, Microsoft suggests that some antivirus software might be marking the web.config or global.asax file as modified, thus causing a new application to be started and subsequently causing the loss of the session state. This holds true also if you or your code modify the timestamp of those files. Also, any addition to or removal from the Bin directory causes the application to restart.
Note: What happens to the session state when a running page hits an error? Will the current dictionary be saved or is it just lost? The state of the session is not saved if, at the end of the request, the page results in an error—that is, the GetLastError method of the Server object returns an exception. However, if in your exception handler you reset the error state by calling Server.ClearError, the values of the session are saved regularly as if no error ever occurred.
I'm assuming you are using Session state in-proc. If this is the case then the most common reason of losing your Session is that the corresponding Application Pool recycles. Go check IIS settings on Application pool and set up Event log entries for such events. You'll find the settings in: "Advanced settings" of your app pool -> "Recycling" -> "Generate Recycle Event Log Entry". Set them all to true and see if it will give you the reason of your Session State loss.
Also if you change data on given sites a lot then it will eventually trigger app pool recycling.
More ideas on app pool recycling:
http://blogs.msdn.com/b/johan/archive/2007/05/16/common-reasons-why-your-application-pool-may-unexpectedly-recycle.aspx