Session

[pjoyce]

I've had to eliminate all session state handing in my application to get it to work. Can you tell us how you have the worker process recycling set? What about using a separate state machine or SQL server state?

[bruce]

Worker process recycle after 10 mins of inactivity.

>What about using a separate state machine or SQL server state?

We are considering this option but it most likely will not be available with this plan.


[b]quote:Originally posted by pjoyce

I've had to eliminate all session state handing in my application to get it to work. Can you tell us how you have the worker process recycling set? What about using a separate state machine or SQL server state?
</blockquote id="quote"></font id="quote">

[bruce]

Just curious, do you know if session state will be stored in the state server? I have been trying to find out about this but couldn't get a definitive answer.



[b]quote:Originally posted by bruce

Worker process recycle after 10 mins of inactivity.

>What about using a separate state machine or SQL server state?

We are considering this option but it most likely will not be available with this plan.


[b]quote:Originally posted by pjoyce

I've had to eliminate all session state handing in my application to get it to work. Can you tell us how you have the worker process recycling set? What about using a separate state machine or SQL server state?
</blockquote id="quote"></font id="quote">
</blockquote id="quote"></font id="quote">

[pjoyce]

Yes, an out-of-proc state server does handle session data. And it actually works, I've never used it in a production environment but I have used it in test and it works rather well. It would be a great advantage to a place like this where you ahve no real control over what people put in their sessions. If it's running on a different machine, it won't affect the performance of the web server. here is a link, I'll see if I can find more:

msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconsessionstate.asp (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconsessionstate.asp)

[CoffeeMug]

The worker process recycling is a very poorly designed feature of IIS 6. I recently had a presentation where the application forwarded to the error page due to this bug (can't really consider it a feature). Not a big deal, but doesn't look good in any case. Do you know if Microsoft is planning to release any fixes related to this issue? Since IIS 6 is fairly new, I could barely find any info on this online.

[bruce]

We haven't heard anything from MS regarding this.

In general, a site with regular traffic should not experience this problem.


[b]quote:Originally posted by CoffeeMug

The worker process recycling is a very poorly designed feature of IIS 6. I recently had a presentation where the application forwarded to the error page due to this bug (can't really consider it a feature). Not a big deal, but doesn't look good in any case. Do you know if Microsoft is planning to release any fixes related to this issue? Since IIS 6 is fairly new, I could barely find any info on this online.
</blockquote id="quote"></font id="quote">

[CoffeeMug]

[b]quote:Originally posted by bruce
In general, a site with regular traffic should not experience this problem.
</blockquote id="quote"></font id="quote">
True, however this is a very real problem at starting stages of application promotion. When you do not have regular traffic and give out your URL to potential clients. I suppose many of your customers are at this stage.

[pjoyce]

Process recycling is, IMHO an absolutely brilliant feature of IIS 6.0 In fact, it's one of the ones MS is rather proud of from what I've seen. The problem is that it exposes a lot of problems that have always existed. Process recycling has an awful lot of settings, too, and people will discover better and worse configurations as time goes by.

It is unlikely that MS will address the problem of threads timing out before sessions time out. There are two more built-in session mechanisms (SQL Server and out-of-proc server) which are much more useful, esp. for web farms where in-proc sessions won't work. In addition to that, developers can use cookies or a database. In .NET it's not that big a deal to create and persist your own session object. Hmm, maybe that would be a good thing to demonstrate here...

Cheers,

Peter.

[CoffeeMug]

The problem occurs even if the thread times out after the session. This isn't just the matter of playing around with the timeout value.

[pjoyce]

I may have oversimplified a bit. Actually, timeout is only one of the reasons that a thread might get terminated. IIS can also be configured to timeout due to a number of different criteria, such as the amount of memory used by your application. See:

www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/standard/ca_recycwrkrprocess.asp (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/standard/ca_recycwrkrprocess.asp)

This is very useful in a hosted environment because it means that if my application goes nuts and starts eating up all of the memory on the machine, it will get killed before it can affect everybody else's web app.

In that sense it's great. It keeps everybody isolated and nobody stepping on anybody else's toes. It means that the people at Discountasp.net don't have to go out and buy 16 new machines every month and they can keep the "discount" in their name.

However, it reveals a very basic problem in the architecture of IIS... And that, of course, is how session works. In IIS, state information is stored in the heap memory belonging to the process which started it (IIS, or actually a thread owned by IIS.) This isn't where it belongs... that works against the scalability of the web application because it means that you are necessarily tied to a single machine. In today's web, even the smaller sites are multi-homed with a load-balancer sitting in front of them. This completely blows away any server-side state management scheme.

I haven't personally used Session on a professional site since IIS 4.0... maybe 3.0. I got suckered into doing it here because this was a small app (NOTE: I now believe there are no small apps.:) and because it was .NET. But I should have known better... In any case, the base problem is that inter-process communication in windows is very slow. Think of old DDE and OLE applications... now scale that wait time to 100 users and you get an idea of how slow it is.

The place where state information belongs is with the client -- That way it doesn't matter what machine the request ends up going to, your application (or some copy of it) will pick the state up from there as if it's running in the same process.

There are two problems with this. The first is that cookies have been used for nefarious purposes and people distrust them. The second is that there is a limit on how much you can store in a cookie. You can't stick an entire huge dataset into a cookie and try to shove it down to the client.. this also impacts your application performance.

So what's the real answer? there are a couple...

1) Don't use state information. You are creating an application for a stateless environment. If you have to re-query the databse, it will probably be faster than pulling the dataset down from the client anyway. (The same applies to viewstate, which is cached on the client side. If you stick a 1MB dataset into viewstate you are sending that to the client via a slow connection and then getting it back. It takes considerably less time to re-query from the DB in most cases)

2) Use a combination of persitent memory (database, for instance) and client. Use some unique ID (NOT USERNAME!) like sessionid or better yet, generate a GUID and pass it along with each request.
3) Any combination of the above. I prefer to go with the more-or-less stateless version, passing what I need in hidden form fields or in rare instances in the querystring.

Cheers!

Peter.
(For those who've made it this far... the reason you don't use username is simple but one that people often overlook... People may and often do open two browsers or share their username. you don't want instance 1 to affect instance 2 of your application.)

[bruce]

We have just consulted with the ASP.net expert regarding this issue.

The answer we got was that this is a feature of IIS 6.0. Using State server will solve the problem and we will kick off a project to look into this matter.

[b]quote:Originally posted by CoffeeMug

The problem occurs even if the thread times out after the session. This isn't just the matter of playing around with the timeout value.
</blockquote id="quote"></font id="quote">