Hi,

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!