Why is this web api controller not concurrent?

Question

I have a Web API Controller with the following method inside:

public string Tester()
{
    Thread.Sleep(2000);

    return \"OK\";
}

When I

Answer 1

Try use this instead:

public async Task<string> Tester()
{

    await Task.Delay(2000);
    return "OK";
}

See this to know the difference between Task.Delay vs Thread.Sleep which blocks http://social.technet.microsoft.com/wiki/contents/articles/21177.visual-c-thread-sleep-vs-task-delay.aspx

Answer 2

You must have enabled the Session State somewhere for Web Api. Web API is restful by default and has no session. Check your global.asax Application_AuthenticateRequest section (this is where I enable session state for Web Api). Find where you enabled your session state at and set it to read-only mode to allow for parallelism on web methods using session state. See this question which is similar: Web API Service - How to make the requests at the server to be executed concurrently

Look for something like this:

HttpContext.Current.SetSessionStateBehavior(System.Web.SessionState.SessionStateBehavior.Required);

Change it to this:

HttpContext.Current.SetSessionStateBehavior(System.Web.SessionState.SessionStateBehavior.ReadOnly);

Answer 3

I don't think I'm answering your question but what I'd like to write here is too big for a comment.

First up, ASP.NET Web API has nothing to do with session state. In fact, if session has to be used with web API, then it needs to be explicitly enabled.

Now, I have the same exact API controller like you and I host it in IIS. If I make concurrent requests, it is running the requests in parallel and not serially. Here is how I tested from Fiddler.

First, I made a GET to the API and waited for 200 status code (#1 in Fiddler left pane). Then, I selected #1 and pressed U to replay the same request unconditionally 9 times. With that I have 10 requests in the left pane (#1 through #10). Then, I selected all 10 of them and pressed R to reissue all the ten requests in parallel. I then selected requests 11 through 20 in the left pane and went to Timeline tab. I see this graph.

PS. I tested the web API running locally, BTW.

Next, I wanted to log the time stamp request as received by the action method. So, I modified action method to return a string like this.

public string Get()
{
    string ts = DateTime.Now.ToString("mm:ss.fff");
    Thread.Sleep(2000);
    return ts;
}

I got the following.

00:43.795
00:43.795
00:45.812
00:44.517
00:43.795
00:43.795
00:45.515
00:43.795
00:43.795
00:43.795

To me this means, all the requests are running in parallel.

Answer 4

Look at this question, which is relative to your problem: Are all the web requests executed in parallel and handled asynchronously?

It states that:

A webApi service, by default, executes all its incoming requests in parallel, but only if the current multiple requests (at a certain time) came from different sessions. That is to say, if single client will send some simultaneously requests to server, all of them will be executed sequentially and won't be executed concurrently.

To solve this, you can use async methods, as described here.

Generally, you need to declare your method as async, like this:

public async Task<MyObj> GetObj()

Answer 5

What you describe matches the default behavior of the ASP.NET Session State and can be solved by disabling it in web.config.

Access to ASP.NET session state is exclusive per session, which means that if two different users make concurrent requests, access to each separate session is granted concurrently. However, if two concurrent requests are made for the same session (by using the same SessionID value), the first request gets exclusive access to the session information. The second request executes only after the first request is finished. (The second session can also get access if the exclusive lock on the information is freed because the first request exceeds the lock time-out.) If the EnableSessionState value in the @ Page directive is set to ReadOnly, a request for the read-only session information does not result in an exclusive lock on the session data. However, read-only requests for session data might still have to wait for a lock set by a read-write request for session data to clear.

Source: ASP.NET Session State Overview