Excessive sessions generated

0
votes

In our production environment (only) an excessive number of sessions seem to be getting created from an ASP.NET web application. The eye-catching symptom was that the ASPStateTempSessions table was generating ~25K records per hour (when google analytics indicates less than 500 unique users on this site per hour). This is resulting in a high number of waiting tasks which is then causing slowdowns and issues across other databases and therefore impeding site performance. The vast majority of the sessions don't appear to have any significant amount of data in them.

Any thoughts on what could be causing the phantom sessions? I was originally thinking that image requests and the like were somehow causing new sessions, but that doesn't seem to be sufficient to explain such a high multiplier. Is that even reasonable? Should I explore that avenue further? Why would that not have the same symptoms in my development environment?

Thanks!

Environment Details (I can provide more details, I'm just not sure what else is relevant):

  • IIS 7
  • SQL Server 2008
  • Session mode is SQLServer:
    • <sessionState mode="SQLServer" sqlConnectionString="[Connection String]" allowCustomSqlDatabase="true" cookieless="false" timeout="120" cookieName="XYZ_SessionId" />
1
asp.netsession-state

1 Answers

0
votes

I agree that the likely culprit is flat files running the SessionStateModule, especially if you are using MVC instead of webforms. The reason is that in order to support extensionless URL routing, MVC adds the following tag into your web.config:

<modules runAllManagedModulesForAllRequests="true">
...

The attribute does pretty much what its name implies, which will cause you to experience overhead if you host images off of the same website in IIS. If you don't use extensionless URLs, you can consider turning off that attribute, or you can try moving images to a CDN like akamai or AWS cloudfront.

Alternatively you could look for a SessionStateModule alternative, there are some that exist that might provider alternate behavior. You could even roll your own by inheriting System.Web.SessionState.SessionStateStoreProviderBase, there is an MSDN article on doing that: custom session provider tutorial. If you do that last one, I recently found ResetItemTimeout to be the most commonly run item on every request by the default SessionState module.

Lastly, the reason I think that the expansion you are experiencing is being caused by this is the fact that SessionState module is synchronous by default. This means a browser requesting both imageA.jpg and imageB.jpg will receive imageA then imageB only after imageA has released the Session lock. This is much slower than the default behavior of a webserver, which is to serve up both on separate threads.

Another way to troubleshoot, if this does not solve it, is to look at the current requests going through IIS7. To do that, go to the top level server name in the left hand side of IIS manager and click on Worker Processes. It should list your website process, double-click that and it will show all current requests. You should see a ton of image files in there.