Input on web service heavy web application

Magnus Rahl
Member since: 2008


I'm currently designing a web application which relies heavily on a back-end service layer exposed as WCF services. I'm now trying to figure out how to expose the data in the way which will handle the largest number of concurrent requests with shortest possible delay.

Because the data will be both personalized and frequently updated caching is no miracle solution here. We will of course cache data but the design must perform as well as possible even when the cache hit rate is very low.

My first idea was to use async pages but it is a bit cumbersome. Instead I'm thinking of using much more partial page loading by ajax requests from the client. Then each part of the page will be loaded asynchronosly and in parallell on the client which will hopefully improve the users' experience in creating the illusion (kind of) that the page loads faster.

To really improve things server-side though, I would also like to be able to complete the processing of the ajax requests asynchronosly. That is, I don't want to use some kind of asynchronous make-ajax-call-to-start-process-and-then-poll-for-changes client side asynchrony, I just want the server side processing to release it's worker thread while waiting for the WCF service call to complete, much like async pages.

So how do I do this? I looked at implementing the ajax end points using async controllers in MVC (even though the "host page" will be implemented in WebForms - it's an EPiServer site). That model looks easy-enough to use and it is simple to serve json to the client ajax calls.

I suppose there's also a way to create a WCF service so that it processes asynchronously without demanding anything special from the client? In that case it would also be an alternative (building one for the web application that is, the web application can not call the back-end WCF layer directly).

Has anyone done something similar? And even if you haven't what are your thoughts from an architecture point of view?

I'm grateful for all input! Thanks!

#57796 Mar 28, 2012 10:55
  • :-)

    If you want to remain in the .NET stack, have an absolute requirement to serve fresh data and must proxy the WCF service I think your plans sounds good though. Considering you're in WebForms I might have looked at creating a regular handler (implementing IHttpAsyncHandler) instead of an MVC controller though.

    #57802 Mar 28, 2012 12:04
  • Magnus Rahl
    Member since: 2008

    Node would be cool but I think I need to keep the methods inside the main web application to share authentication, data etc.

    Yeah, a custom handler could work too. I just thought it would be easier using MVC since you get routing/parameter handling and json formatting "for free".

    the MVC4 WebAPI looks interesting too but I'm not sure how EPiServer would handle MVC4. And I don't know if there's an Async pattern for WebAPI (though I assume there is).

    #57805 Mar 28, 2012 13:14
  • David Knipe
    Member since: 2008

    Frederik has already blogged about using the WebAPI framework in EPiServer so this could be a good starting point:

    Did the EPiBorg miss this one ;)?

    #57806 Mar 28, 2012 15:00
  • Magnus Rahl
    Member since: 2008

    Yada yada... ;) From time to time I actually have to do some work and that could mean I miss a post or two :) Thanks for the link, I'll check it out!

    #57817 Mar 28, 2012 18:48
  • Magnus Rahl
    Member since: 2008

    Ah, Web API can run without MVC 4, great! And it seems quite easy to implement async controllers using the task-based programming model:

    Too bad .net 4.5 isn't released, using the async/await style would be some extra sugar. :)

    #57823 Mar 29, 2012 8:14