Even though I've set-up the recommended SQL session management and set the sessionState timeout, and the authentication -> forms timeout to 2880 minutes, my session is still timing out after around 30 minutes. I confirmed that the IIS7 control panel was reading my web.config settings correctly and everything. I see others are having this issue. What's up with that?
I suspect that your site is using some form of cookie and viewstate along with your session. When I ran through your test, I checked the server and you steadily built the memory usage. Infact when I logged off your application did not release the memory but kept it. So when I logged back in it gradually built up until it passed 100 MB. Remember, sessions are only one part on how the browser keeps track of your activity in a website. There ares sessions, cookies, and viewstate. The sessions are being held outside of the server, but viewstate and cookie values are still within the web server. So, when your application pool is recycled, the browser looses the page where you are suppose to be and puts you back into the login page. The only work around to this is to make sure your web application does not consume 100 MB of the servers memory.
Is there any way to monitor memory consumption at my end? I don't feel my application is written poorly--I'm using Entity Framework to manage all data calls, etc. So, having a way to keep track of it would help. However, you are incorrect that it's just a perceived session state loss based on page name loss. There are various objects that display (or not) on any page based on having a valid session. These are also gone... it is not just a page change. So, the session, despite the DB tie, is being lost. I only use the default sessionState parameters with a valid timeout (which is also set in the forms authentication setting)... something's off. Oh well, I will try the same test(s) on standalone servers and see if switching to a VPS might help. <sessionState mode="SQLServer" timeout="2880" allowCustomSqlDatabase="true" sqlConnectionString="Data Source=tcp:sxx.Winhost.com;Initial Catalog=DB_xxx;User ID=DB_xxx;Password=xxx;Integrated Security=False;" cookieless="UseCookies" cookieName="xxxSessionId" xdt:Transform="Replace" />
No, I'm afraid there is no way you can monitor the memory usage on the server. That will require you to gain admin rights to the server which we cannot give you because this is a shared hosting environment. I think you maybe misunderstanding my last post. You believe that sessions are being lost even when they are tied to the SQL server. I can assure you they are not. You can verify that yourself by pulling up your site and logging into it, then using SQL Server Management Studio connect to our SQL 2008 server an unto your database and you will see your session there. Even when the application pool is recycled you will still see the session in the database. But since you use other objects such as cookies and viewstate, the browser is loosing its place on your website and thus make it seem that you are getting kicked out. As hard as it is to believe your application pool over time eventually reaches 100 MB. Now, the first initial call doesn't reach 100 MB. Like I said it slowly builds up. When you log out of the form the memory is not released. Typically it should be released but its not. That is why after numerous logins, your application pool eventually reaches over 100 MB.
Yeah, I'm not sure it all makes sense, but I'll live. For instance, the session loss happens at the exact same time (duration) every time regardless of activity. Secondly, nothing about my application changed except moving to the SQL session host and the timeout interval on my sessions went from two minutes to 20 minutes (fixed amount of time). Considering the issue referenced is that I exceed the 100 MB cap in both situations, that would be telling me that using InProc session vs. SQL session causes me to arrive at 100MB memory 10x faster. Something's not right with this explanation, but again, I will live.
Well, I spent a lot of time optimizing my DB calls with using { } statements and I was able to get session to now persist for a longer interval. I see that reducing memory usage does improve this issue. Just an FYI for everyone.
Yep. I suppose for the amount I pay and receive mostly great everything else but 100 MB of memory, I cannot complain. One other trick: I made the "remember me" checkbox preserve the user's name and password to cookies. So, despite the slight security headache, when the user gets bumped (around an hour after my improvements, although my timeout was 2880 minutes), they can just click login again with no typing needed
The 100MB (or 200MB for the Max and Ultimate plans) limit is necessary because we run each site in its own application pool. In hosting, more memory = increased cost to you. The larger that application pool, the fewer sites can live on the server. If we allocated 500MB of memory to every site we would have to drastically reduce the number of sites per server, and that would result in a significant price increase. That's just on of the unavoidable truths about the hosting business. The reason you may see posts here from people running in to the problems with those limits after having an application run at another host, is typically because that other host did not run the sites in isolated application pools. That means that conceivably, every site had access to a huge chunk of the available server memory. That sounds great from a consumer standpoint -- until you realize that they put just as many sites on a server as we do. That means all those other sites on your server can also use huge chunks of server memory, and you are all swimming in the same "memory pool" as it were. So if/when half a dozen other sites on your server suddenly decide to use a gig of memory, what happens to your application's memory needs? They may not be met. The memory may not be there to use. Even worse, any one of those hundreds of other applications running on your server can crash the application pool that you all share. Then your site - and everyone else's - simply dies. Not cool. That's one of the reasons that we run each site in its own application pool. If your neighbor's site is a horrible monstrosity that attempts to consume 8 gigs of memory every time it starts, it will only crash his application pool. Yours will be unaffected. The downside of that protection is, as you've seen, your memory limit is constant, so you have to figure out how to work within it. But really, in the scheme of things, 100MB is a lot of server memory. Optimizing your application to work well within that limit is a good thing. It will make for a better experience for your users.
Hi there, This was a very informative thread for me. Would it be possible for you to check the same on my site? I am having the exact same issue and have pushed my session storage to sql server. I'm not depending on cookies but have timeout issues. If so, where can I email you my site address, username and password?? Cheers, Hamish.
Please contact the technical support department by submitting a ticket through the support portal. We will take a look at the server's logs and tell you if you application pool is being recycled automatically.
