Concurrency in web applications

Question

So recently there has been a lot of emphasis by almost all platform providers to provide new tools/language constructs for better concurrency. And that is also one of the reasons why a lot of ideas from functional programming languages are being integrated into mainstream languages like C#, Java etc.

Even though these make a lot of sense today specially with the introduction of multi-core CPUs, but I wanted to know how one can use these in specially in the domain of web applications. In web apps a lot of the concurrency is managed by the web server itself and very seldom do I see multi-threading implemented inside web pages. AJAX also enabled "pagelets" like paradigm to help further.

Web applications typically consist of fetching results quickly and till now we utilized many tactics like caching, redundancy etc. to achieve this goal. If there was something that was compute intensive it had to happen offline (and the clients could query for the results later or callbacks could be implemented).

Concurrency kind of is already implemented in a lot of libraries/frameworks that are typically used in web apps like database, multi-gets in frameworks like memcached.

I couldn't find a lot of sample scenarios in which the recent concurrency platforms and libraries can be used in context of web apps. So I would like to know if they make a lot of sense in the web domain.

Answer 1

Because web apps are concurrent by default, you'd be less likely to use new concurrency mechanisms (such as TPL or PLINQ for .NET) in web applications. You will usually gain nothing on a web server with a high load (you would speed up one request, by slowing down another request). However, when you've got a dedicated web server that's not serving for most of its CPU cycles (while having multiple cores), those techniques might be useful.

[Update:] Just read a new article on the Parallel Programming with .NET blog. Here are two interesting quotes:

In most cases, and in particular for Web applications with heavy usage, it is probably not necessary to introduce extra parallelism since adding more work items will only result in competition for CPU time and ultimately reduce request throughput.

and:

Web applications that need to perform expensive computations may still benefit from parallelism if the latency of an individual request is more important than overall request throughput.

I think this answers your question.

Answer 2

The strict view of everything being synchronous and consistent is not scaling well enough. There is then a tendency to have more stuff asynchronous and to accept eventual consistency. This also reflects in the way languages and framework are designed.

Lots of inspiration is drawn from the functional area because it fits well with this mode of computation. Functional programming helps to reason about what to perform rather than how and when.

This actually complements the otherwise traditional mechanism to deal with concurrency.

I couldn’t find a lot of sample scenarios in which the recent concurrency platforms and libraries can be used in context of web apps. So I would like to know if they make a lot of sense in the web domain.

This depends on what you mean. You won’t necessary need to use low-level construction such as the one in java.util.concurrent. But asynchrony is supported better and better along the framework stacks. For instance, Servlet 3.0 introduces asynchronous web request to ease the development of AJAX applications. As a consequence, EJB 3.1 have asynchronous method invocation to integrate with the asynchronous web layer. At the bottom we have the low-level abstraction of function (or delegate, closure) which abstracts the computation itself, and the information necessary for the computation (its context). I guess the same is true for .NET.

Not related to traditional web application, but rather to the web as “the cloud,” functional programming helps with distributed computation across CPU and nodes. A well-known example is map/reduce and the likes, which aim at processing large set of data.

All that fits together, and we see a web application which stays responsive, while large set of data are processed asynchronously.

But no, you won't necessary need all that for a traditional web app!