Asp.net MVC async is slow

Question

I am using Entity Framework 6.0.0 alpha1.

In my Asp.net MVC app, I have two controller:

One is without async:

    public ActionResult Index()
    {
        return View(db.Movie.ToList());
    }

One is with async:

    public async Task<ActionResult> Index()
    {
        var model = await db.Movie.ToListAsync();
        return View(model);
    }

I use ab tool to test the performance:

Result without async:

Server Software:        Microsoft-IIS/8.0
Server Hostname:        localhost
Server Port:            60863

Document Path:          /movies
Document Length:        5724 bytes

Concurrency Level:      10
Time taken for tests:   21.229 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      6071000 bytes
HTML transferred:       5724000 bytes
Requests per second:    47.11 [#/sec] (mean)
Time per request:       212.290 [ms] (mean)
Time per request:       21.229 [ms] (mean, across all concurrent requests)
Transfer rate:          279.27 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       4
Processing:    66  211  71.3    195     806
Waiting:       66  211  71.3    195     806
Total:         67  211  71.3    196     807

Percentage of the requests served within a certain time (ms)
  50%    196
  66%    223
  75%    245
  80%    260
  90%    298
  95%    334
  98%    397
  99%    461
 100%    807 (longest request)

Result for async:

Concurrency Level:      10
Time taken for tests:   29.495 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      6071000 bytes
HTML transferred:       5724000 bytes
Requests per second:    33.90 [#/sec] (mean)
Time per request:       294.947 [ms] (mean)
Time per request:       29.495 [ms] (mean, across all concurrent requests)
Transfer rate:          201.01 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       2
Processing:    69  293 160.0    244    1546
Waiting:       69  293 160.0    244    1546
Total:         70  294 160.0    245    1547

Percentage of the requests served within a certain time (ms)
  50%    245
  66%    295
  75%    343
  80%    373
  90%    507
  95%    639
  98%    772
  99%    841
 100%   1547 (longest request)

My question is why the async is slow?

shouldn't the second implementation be returning a task rather than a view? — Yaur, Apr 15 '13 at 14:42

Robert Harvey · Accepted Answer · 2013-04-15T14:48:51.993

7

Are you testing how soon the async call returns so that you can get other work done, or are you waiting for the work to complete? Async doesn't magically make work get done faster; it just unblocks your method calls so that you can do something else while the work gets done.

In fact, if you're waiting for the work to get done, async is going to take slightly longer, because it adds some overhead.

What you really should be measuring is scalability, not speed. A synchronous website is going to service the first few calls faster, but slow down as you add additional load. A well-written asynchronous web site should handle a greater number of calls more consistently and reliably, because your using the processor cores more effectively.

To improve overall scalability and responsiveness, look for long-running operations that you or the user don't have to wait on for completion, and make those asynchronous.

edited Apr 15 '13 at 14:48

answered Apr 15 '13 at 14:36

Robert Harvey

178,213
47
333
501

Thank you, but how do I measure scalability? – Alvin Apr 15 '13 at 14:44
Async methods are useful when you have multiple tasks that do not depend on eachother. Otherwise there isn't any point in adding the complexity to make them asynchronous. Another potential win is when you depend on external services that may not return immediately--a long-running db query or web service-- _and_ there is something else productive that your code can be doing while you wait. Otherwise, just keep it simple. Your async call runs on a thread from the same thread pool that ASP.NET itself uses, so you don't automatically free up any ASP.NET resources by going async, either. – Craig Tullis Apr 16 '13 at 01:45
1

@Craig: I should add that extensive use of async is probably not needed unless there will be many users (for some arbitrary value of many). – Robert Harvey Apr 16 '13 at 01:46
I was out of space... (agreed) :-) – Craig Tullis Apr 16 '13 at 02:32
1

I guess I would also add that just in a general sense, "speed" and "scalability" are sort of fundamentally different things. This is way oversimplified, but maybe think of it like this: "speed" means that a page will return in, say, 500ms. Scalability means that a page that returns in, say, 1000ms will _still_ return in not much more than 1000ms with 200 concurrent users (or a number of users equal to "some arbitrary value of many"). Just because an app is fast doesn't mean it can scale, nor is an app that can scale necessarily the very fastest when serving few pages to few users. – Craig Tullis Apr 16 '13 at 02:46

Asp.net MVC async is slow

1 Answers1