Our team is mantaining and developing a .NET web service written in C#. We have stress tested the web service’s farm and we have evidence that the actual architecture doesn’t scale well, as the number of requests are constantly increasing.
We analyzed Martin Fowler’s conclusion in this article, and our team feels that migrating to an asynchronous programming model such as the one described could be the right direction to point to for our service too. My question is: do you think that this “switch” needs a complete rewrite of the application? Has been someone of you been able to adopt APM without rewriting everything and has some insight to share?
Thank you in advance
3
Use the async and await keywords in C# 5.0. These keywords allow you to insert the async functionality into the method calls that require it, without having to create callback mechanisms. The callbacks are created for you automatically by the compiler, under the covers. This should greatly simplify the refactoring effort.
Anders Hejlsberg describes the async functionality in this video, with a detailed example application and demonstration.
1
If moving to C# 5.0 is not an option, then I am afraid you will have to fallback to the more traditional approach of using callback functions. I once migrated a thick client application using this approach.
Every application is different so it is hard to predict how much rewrite you’d need but in my experience, it was never overwhelming. What took more effort was the gotchas that come with asynchronous programming. I can highlight two:
-
First and foremost, you’d need to think about your application flow and figure out which parts of the application should remain disabled when an async operation is running. If an application has not been designed with this in mind then it can take a lot of effort to maintain state information and logically grouping the sections that should go disabled together etc. If your application is a server, then you may not run into this complication.
-
Second, and this has universal applicability, you will need to come up with a way to recover the information
from differentBeginAsync(...)calls. One way to do this is to pass the
function and its arguments in the call back object itself. You get a
reference to this object in theEndAsync(...)method. An obvious
gotcha there is to make sure you are able to distinguish one
BeginAsync(...)call from another one on the same method.
I am not saying that you can avoid thinking of these issues with the newer API. These are common issues with async programming in general –in any framework or language. But once you write some async code and get it to work correctly, it becomes second nature to think this way.
Bits that are blocking are calls to external services whose response is needed in order, for our service, to provide a meaningful response.
Is there more processing you could do while waiting for the response from these external service calls? If not then you are out of luck async will only buy you performance if you are able to do more in parallel.
On the other hand if these external services are the only thing needing to be executed in parallel, I would look into futures, they seem like a good fit for kicking off a service call then doing something else while waiting for the result as well as the fact that they would be minimally invasive to your current design.
2