Alternatives to HTTP Session state in plain-vanilla .NET web services app

Throw more hardware at it!

No, seriously. For sites like yours, you might benefit from configuring a separate machine as a session state server (see MSDN documentation), which you can do from the IIS GUI or commandline.

After you have the state server set up, you need to set up your web config to use the new machine. A nice description of the process is available here, but in short, you set the web.config's system.web.sessionState element as follows:

<?xml version="1.0"?><configuration>    <system.web>        <sessionState            mode="StateServer"            stateConnectionString="tcpip=your_server_ip:42424"            cookieless="false"            timeout="20" />    </system.web></configuration>

Now if you want to go real heavy duty, you can have many state servers and write your own routine for resolving which server contains your session state. See a description of the process here. This strategy should help you scale more or less indefinitely without abandoning your use of HttpSession.

If most of your requests only require read-access to the session then you have a simple solution. Set the EnableSessionState attribute to ReadOnly and they're acquire a read-only lock on the session only. I'm not sure how to apply this to web servcies, but I'm sure there is an equivalent setting.

http://msdn.microsoft.com/en-us/library/aa479041.aspx#aspnetsessionstate_topic3

Other than that, ASP.NET locks the session object for the entire duration of each request and effectively serializes the requests. One solution to allow requests to run in parallel is not use the built-in sessions and roll your own solution. The advantage here is that you can use much finer grained locking so certain aspects of the requests will have to by synchronized and will run serially, but the majority of each request can run in parallel.

An alternate solution is to simply reduce the number of parallel calls per request. Don't try to run them in parallel at all. Batch them up on he client side and send them as a single request. You'll end up with less overhead in the number of requests, less likelihood of a single client hogging a lot of resources, and very likely can get better performance overall and for each aggregated request.

It's really easy to fix your problem.

1. Turn off session in your web.config for the entire web site

2. Create a table in sql server:

   create table Session( SessionId int (or a guid) ... ...)

3. Create separate tables that have a foreign key back to your session table (with delete cascade) and that store session specific information

4. On the application side, either store the SessionId in a cookie or in the query string. You can then look up all the session information you need on-demand. This will work a lot faster than the default session state providers, since you only get information when you need the information! Also, you don't have to carry the default session object on your back any longer.