0

I have a web site which I developed using C# and Visual Studio.

I noticed that in debug mode in visual studio(but with no break points) when I am on a page and pressing many times F5 to refresh the page, it takes a long time to serve all the requests till I get the last response to the browser. Meanwhile, when trying to access the site from a different browser session, I am waiting for a response from the server which is busy and doesn't respond.

Doesn't IIS work asynchronously when serving requests to clients?

Gidi
  • 181
  • 1
  • 10

3 Answers3

6

Yes, IIS can serve multiple requests to clients in parallel, but if you are using session state in ASP.NET, then by default requests from a single session will be served sequentially (so that there's no possibility of two threads accessing the session state at the same time).

Your question is not clear if 'debug mode' means "with a debugger attached to the web server" or "when I compile my application with the 'debug' options" - if it's the former, then all bets are off as far as parallel operation is concerned - attaching a debugger almost always changes threading behaviour.

Will Dean
  • 39,055
  • 11
  • 90
  • 118
  • ooh, good spot; I usually disable session state, so I forget some of the nuances it creates – Marc Gravell Nov 26 '13 at 08:30
  • anecdotally, I usually observe plenty of parallel load even when running inside the debugger – Marc Gravell Nov 26 '13 at 08:31
  • @WillDean what I mean is running under debug mode in visual studio (but with no break points) – Gidi Nov 26 '13 at 08:39
  • @Gidi Does the problem go away if you don't attach the debugger? – Will Dean Nov 26 '13 at 08:45
  • @WillDean no it doesn't. I stopped the debugger and still the same. although the waiting time reduced (from ~10 minutes to ~3 minutes)... – Gidi Nov 26 '13 at 08:48
  • Gidi - if it's not debugger related, then you probable need to provide more info about your framework etc - if you're using ASP.net MVC then session state is on by default, and that may well cause this sort of behaviour. – Will Dean Nov 26 '13 at 08:52
  • @WillDean yes I am using ASP.net MVC. should I change it? should it affect also the production sever? – Gidi Nov 26 '13 at 08:59
  • @Gidi - I think you need to edit the question to clarify more detail about your setup and that this is nothing to do with the debugger, and whether or not you're seeing differences between the behaviour of different servers. People are perhaps not answering the question you're trying to ask. – Will Dean Nov 26 '13 at 09:01
  • 1
    @Gidi to clarify: no, there is no fundamental issue with ASP.NET MVC here; don't randomly start carving that out (not that I'm sure where you'd even start); ASP.NET MVC works perfectly fine with concurrency; whatever problem you are having relates to *something in your setup* – Marc Gravell Nov 26 '13 at 09:59
2

IIS and ASP.NET are heavily concurrent. Whether it runs requests from a single client concurrently is up to IIS etc. However, it isn't always possible to detect a disconnect - so if each request hammers the server, it could take a while to finish. The tip there is: don't write slow pages. Set a target time that you want to respond within, and use a tool like mini-profiler to check how you are doing, and what is taking the time. Our target internally is about 30ms, but most folk will probably want to aim for 1s initially, then 0.5s, etc.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
1

When you are debugging and stopped at a breakpoint, all threads are frozen. Thus the other requests are queued up and waiting to be processed.

Ed Chapel
  • 6,842
  • 3
  • 30
  • 44
  • 1
    It should perhaps be noted that this mainly applies to *when at a breakpoint/pause* - not simply running inside the debugger. – Marc Gravell Nov 26 '13 at 08:29
  • @MarcGravell what I mean is running under debug mode in visual studio (but with no break points) – Gidi Nov 26 '13 at 08:41