3
votes

IIS (or maybe ASP.NET) takes longer time to respond requests when they are sent simultaneously with other requests. For example if a web page sends request A simultaneously along with 20 other requests, it takes 500 ms but when this request is sent lonely, it takes 400 ms.

Is there a name for this feature? It is in IIS or ASP.NET? Can I disable or change it? Is there any benefits using it?

Notes:

  • I am seeing this issue on a ASP.NET Web API application.
  • I have checked IIS settings (IIS 8.5 on Windows Server 2012 R2) and found nothing that limit its throughput. All constraints like band-with and CPU throttlings are at high number. Also the server have good hardware.

Update 1: All requests are going to read something from database. I have checked them in Chrome developers' console. Also created a simple C# application that makes multiple parallel requests to the server. When they are really parallel, they take a large time, but when makes wait between each call, the response time decreases dramatically.

Update 2: I have a simple method in my application that just sends an Ok:

[AllowAnonymous]
public IHttpActionResult CheckOnline()
{
    return Ok();
}

Same behavior exists here. In my custom C# tester, if I call this route multiple times simultaneously it tokes more than 1000 ms to complete but when wait 5 seconds between each call, response time drops below 20 ms. This method is not IO or CPU bound. Seems that IIS detects that these requests are from a single specific user/client so do not make too much attention to it.

1
It is really hard to answer any of your question. Apart from no - there is nothing in ASP.Net that limits parallel requests execution. However, I have a list of questions for you: a) How have you measured it? b) what do these call do? are they using a common resource that is locked for one thread only? c) have you measured an empty call to an endpoint (say a reply that only returns "OK") does it also have the same problem?trailmax
@trailmax Please see update 1. I will do my tests over an empty call and update again. It is a good point to notice.Afshar Mohebi
@trailmax Please also see Update 2Afshar Mohebi
By the sound of your second update, there is something that is getting deadlocked - it should not do this. Session can be one suspect. Another can be bits of MVC running in your pipeline and that can bring Session without asking you. Were there any MVC in your app before?trailmax
It is an ASP.NET Web API application based on OWIN and Helios (no system.web.dll). I can not find any sign of MVC.Afshar Mohebi

1 Answers

1
votes

If you use ASP.NET Session in your application, requests are queued and processed one by one. So, the last request can stay holt in the queue while the previous requests are being processed.

Another possible reason is that all threads in the ASP.NET Thread Pool are busy. In this case, a new thread will be created to process a new request that takes additional time.

This is just a theory (or my thoughts). Any other cause is possible.