1

I wrote a test page that does a bunch of busy work in a method called at page load. This process as I have it now takes around 12 seconds.

If I try to load another page while the first long running page is loading, this second page doing nothing except writing out a hello world, it doesn't load until the first long running page is finished.

Why is this the case? I would think IIS would be able to handle multiple concurrent connections, it seems crazy that one long running page would stop every other page in the application from loading. I must be missing something or not understand how IIS works.

I would think multiple independent requests would be spawned on different threads. Is this only the case if the requests are from different sessions entirely? Are all requests from a single session bound to a single thread?

bd

BrooklynDev
  • 900
  • 2
  • 12
  • 25
  • Is this happening in production or on your development pc? Have you got a debugger attached to the worker process? – Kev Oct 11 '10 at 23:02
  • Both our Stage server running IIS 6 and my local machine running IIS 7 on Server 2008 R2 seems to exhibit the behavior. – BrooklynDev Oct 11 '10 at 23:23

3 Answers3

6

You need to turn off sessionState... if session is on, any sub-sequent request is waiting on the previous thread to finish in order to continue on that particular session.

So turn session off, it will not need to wait for any previous session.

in web.config put

<system.web>
    <sessionState mode="Off" />
</system.web>

Now you should have those request process concurrently.

ChrisW
  • 54,973
  • 13
  • 116
  • 224
Basslover
  • 76
  • 1
  • 1
5

I just hit this issue too, and for me it turns out it is the session feature of ASP.NET. Basically if you have sessions enabled, each request will return in the order it arrived per user.

Try using 2 different browsers, for me it no longer blocked. Here is a similar question:

IIS 5.1 on XP Classic ASP appears to be in single threaded mode

Community
  • 1
  • 1
Iain
  • 10,814
  • 3
  • 36
  • 31
0

It's a threading problem. While IIS can handle multiple connections simultaneously, ASP.NET, by default, is configured in single-threaded mode.

This choice by Microsoft was to prevent dummy developers to make common concurrency mistakes. ASP.NET for Mono doesn't show this behaviour and if you access shared resources without prior locking you might be... f... you know ;) by a yellow page of death.

I don't remember the exact procedure, but in the properties of your website you can choose the application pool and also the number of threads. I saw with my eyes that IIS6 sets it to 1 by default.

If you can't find it, tell me and tomorrow I'll take a look on my development server in lab.

Hope to have been of help.

usr-local-ΕΨΗΕΛΩΝ
  • 26,101
  • 30
  • 154
  • 305
  • I looked over IIS 6 and 7 but couldn't find a threat count attribute, just an entry for number of processes. I did some research and it seems you can configure threading using a couple .config files but I'm not sure that solves my issue as the default value for threads per process is like 10-40. – BrooklynDev Oct 12 '10 at 01:48
  • Adding threads does solve your problem. Try adding processes and see if it works the same... – usr-local-ΕΨΗΕΛΩΝ Oct 12 '10 at 15:35
  • But the thing is the default value for threads per process is not 1. So it's not the total number of threads per process that's the problem. For some reason multiple requests act as if they are being handled on the same thread, that's the problem. I wonder why that is. Are all requests of a single session processed on 1 and only one thread? Not knowing more about how IIS works under the hood this seems like my best guess as to what's going on. Adding processes 'web garden' is a different feature entirely, and would require me to store session out of process and is way overkill for a simple app – BrooklynDev Oct 12 '10 at 18:07