使用异步和等待.NET 4.5 MVC C＃

Question

I've been experimenting with some old code that needs refactoring in places and was testing if there was any improvement to iis threads etc by uploading file asynchronously (Server Side). Using jQuery file upload client side.

The original code

[HttpPost]
public ActionResult UploadDocument( HttpPostedFileBase uploadedFile ) {

  // Do any validation here

  // Read bytes from http input stream into fileData
  Byte[] fileData;

  using ( BinaryReader binaryReader = 
          new BinaryReader( uploadedFile.InputStream ) ) {

    fileData = binaryReader.ReadBytes( uploadedFile.ContentLength );

  }

  // Create a new Postgres bytea File Blob ** NOT Async **
  _fileService.CreateFile( fileData );

  return Json(
    new {
      ReturnStatus = "SUCCESS" // Or whatever
    }
  );

}

The new code

[HttpPost]
public async Task<ActionResult> UploadDocumentAsync( HttpPostedFileBase uploadedFile ) {

  // Do any validation here

  // Read bytes from http input stream into fileData
  Byte[] fileData = new Byte[uploadedFile.ContentLength];

  await uploadedFile.InputStream.ReadAsync( fileData, 0, uploadedFile.ContentLength );

  // Create a new Postgres bytea File Blob ** NOT Async **
  _fileService.CreateFile( fileData );

  return Json(
    new {
      ReturnStatus = "SUCCESS" // Or whatever
    }
  );

}

The new method appears to work correctly but my question is:

Is the following code the correct (best) way to do it? and are there any gotchas doing it this way? There is a lot of contradictory and out of date information out there. There also seems to be a lot of debate on whether there is any improvement or point in actually doing this. Yes it give back threads to iis etc but is it worth the overhead type of debate.

The code in question

// Read bytes from http input stream into fileData
Byte[] fileData = new Byte[uploadedFile.ContentLength];

await uploadedFile.InputStream.ReadAsync( fileData, 0, uploadedFile.ContentLength );

Answer 1

The code is correct. Using async IO is not all or nothing. You can safely mix sync and async IO, as you have done.

Whether you should be using async has been covered already. For ASP.NET the basic rule is to use it in cases where the operation might have a really high latency and is being invoked a lot at the same time. Only in that case is it important to not free threads. If the operations are quick or rare then there are not many threads to free and this is a waste of developer time.

Reading from a buffered (default) input stream is the same as reading from a file. ASP.NET buffers long inputs to files on disk. This is a classic case where async IO does not provide gains in throughput. In fast the file is likely fully cached so that the IO is purely CPU based (a memcpy from the cache). Total waste of dev time and CPU cycles. No benefits at all.

Answer 2

To answer your questions specifically:

1. There's nothing wrong with your code, and in my opinion you should go forward with that change. Depending on a variety of factors (file sizes/buffering as pointed out, concurrency, etc), it may or may not make a noticeable improvement (and any improvement will be in scalability, not speed), but you will almost certainly not be worse off. The "overhead" you speak of involves the state machine written by the compiler, and it is nearly negligable in most situations.

2. One minor gotcha I can think of: You'd want to take a look at what's happening after await and make sure there's no assumptions that that code will be running on the same thread as the code before the await . Not likely in this case, but something to be aware of.

I would disagree with the notion that async is a "fad" with few good uses on the server. It's a direct response to hardware trends. Processor speeds are not increasing at the rate they once did. Today the race is for more cores, and we're seeing programming languages and frameworks react to that trend with features that make it easier to write software to take advantage of that hardware-level concurrency.

Relatively long-running I/O is commonplace in server applications (working with files, calling external APIs, etc), and freeing threads to do other work during those operations is almost always a benefit.

Answer 3

For all the trouble you are putting into async await you might be able to do something like this:

try
{
     Task.Run(() => uploadedFile.InputStream.Read( fileData, 0, uploadedFile.ContentLength ));
}
catch()
{
    // etc.
}

This will buy you parallism where you need it (which async does not necessarily give you) and you can spend a little time will a websocket framework like signalR to return your success/failure result.

BTW you can probably put a lot more code in that task.. including calls to your db. I just posted that as an example.

EDIT ..... Per comments below the point of my answer is that in many cases horsepower can be directed and used with much more prescision with tasks versus async / await. This is not a slam against async await, just a matter of using the right tool for the job. Here is some code from a production server that does just exactly that:

        Task t1 = Task.Run(() => GetBusinessProcesses(-1));
        Task t2 = Task.Run(() => GetActivityRoles(-1));
        Task t3 = Task.Run(() => Tools = toolService.GetTools().ToSelectListItem(x => x.Name, x => x.ToolId.ToString(), true).ToList());
        Task t4 = Task.Run(() => BusinessAreas = businessAreaService.GetBusinessAreas().ToSelectListItem(x => x.Name, x => x.BusinessAreaId.ToString(), true).ToList())
            .ContinueWith(t =>
        {
            // Populate the functional area dropdown data
            if (BusinessAreas != null && BusinessAreas.Any())
            {
                int businessAreaId = System.Convert.ToInt32(BusinessAreas[0].Value);
                GetFunctionalAreas(businessAreaId);
            }
        });

        try
        {
            Task.WaitAll(t1, t2, t3, t4);
        }
        catch (Exception ex)
        {
            throw new Exception("Error populating dropdowns.  See inner exception.", ex);
        }

In the code above I make four parallel calls to my db and build four lists in parallel. I wait on the tasks and return the page. In the OP's case he can do:

    Task t1 = Task.Run(() => parse the file).ContinueWith(x => write to the db);
    Task t2 = Task.Run(() => more work);
    // do some work here
    Task.WaitAll(t1, t2);
    // Return the page