IIS doesn't send two responses to the same client at the same time (only for ASP)

Question

I've got 2 ASP pages.

I do a request to the first page from Firefox (which takes 30 seconds to process on server-side), and during the execution of 30 seconds I do another request from Firefox to the second page (takes less than 1 second in server-side), but it does come after 31 second. Because it waits first requests to finish.

When I request to the first page from Firefox and then request the second page from IE it's just instant.

So basically ASP - IIS 6 somehow limiting every client to one request (long processing request) at a time. I need to get around this problem in my .NET client application.

This is tested in 3 different systems. If you want to test you can try the ASP scripts at the end.

This behaviour is same in a long SQL execution or just in a time consuming ASP operation.

Note:

• It's not about HTTP Keep Alive
• It's not about persistent connection limit (we tried to increase this in firefox and in .NET with Net.ServicePointManager.DefaultConnectionLimit)
• It's not about User Agent
• This doesn't happen in ASP.NET so I assume it's something to the with ASP.dll
• I'm trying to solve this on the client not the server. I don't have direct control over the server it's a 3rd party solution.

Is there any way to get around this?

Sample ASP Code:

First ASP:

<%
Set cnn = Server.CreateObject("Adodb.Connection")
cnn.Open "Provider=sqloledb;Data Source=.;Initial Catalog=master;User Id=sa;Password=;"
cnn.Execute("WAITFOR DELAY '0:0:30'")
cnn.Close
%>

Second ASP:

<%
Response.Write "bla bla"
%>

Answer 1

Have you tried to use Response.Flush? That might cause the buffered output to be sent immediately.

Answer 2

Is IIS (or this website in specific) set to have 1 max. concurrent connections?

Answer 3

This is due to the way ASP manages Sessions. The Session object is single threaded and hence can only be accessed by one worker thread at a time. When a second request arrives for the same session as is already being handled by an existing thread that request is queued by ASP until the session object is avialable.

This happens by default even if you do not actually use the session object in the pages in question.

Hence when you were making one request from FF and the other from IE you would have two different sessions thus both requests can proceed simultaneously. You could have got the same effect using two distinct instances of IE.

If you know you never need the session object you can go into Application configuration and turn it off (this would mean no ASP page ever touches the session object). In this case ASP would allow multiple requests from the same browser instance to be processed at the same time (because it would have no way to know the requests were from the same browser instance).

However in most cases ASP code has some use for the session object (even its just marking a session as logged in). In this case you are stuck with this behaviour unless you separate the two ASP pages being called into separate applications.