Hi there!
We have some number of IIS 7 running on Windows Server 2008 with .Net 4 and session state on SQL Server. The servers are behind a firewall and a loadbalancer, serving hundreds of users without a problem. Most of the time this works good, no queued requests on the IIS. But sometimes our IIS get blocked, all of them building up a queue. The "current requests" in the worker process view of the troubled application pool shows - among others seeming normal - a huge number of requests from one single IP, all in RequestAcquireState. The requests seem not from a DoS or other mean attack, just normal requests, but fired repeatedly instead of once. The lock seem to be inside session state logic, the lock on the session itself. The database server itself only shows "blkby" (blocked by) in sp_who2 on the ASPState database if there are a really high number of such simultaneous requests.
I am aware, that IIS serializes requests from one source, since it can access the sessionstate only for one request at a time. But in our case, these hundreds of requests from one IP (mostly on the same URL, a page requiring sessionstate) block our IIS, filling up the queue and therefore blocking out other requests from being processed. Since the loadbalancer distributes these requests over all our servers, all endure the same problem and therefore our site gets either very slow or completely down, until the requests from the single IP time out or get served one after the other. This can not be normal for IIS?
Until now, we get alarmed by the queues building up on the IIS, shown by perfmon and also by some other connectivity-monitoring tools. Our only way to handle it is to block the IP on the firewall (otherwise they would simply build up again) and then performing an IISreset on all servers, getting rid of the blocking requests.
Is this really normal behavior for IIS 7? Why don't these requests from the same IP get queued letting the requests from other sources being processed?
Is there a way to prevent this situation?