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

Sure concurrency platforms make a lot of sense in web apps. Just look at SO (and the multi-tenancy framework StackExchange) for instance - there has to be many cases where the same object (question, answer, etc) is being updated 'concurrently'. This would be a large consideration of such software i'd imagine.

Answer 2

Yes, in high performance server and long running tasks

Check out Async controllers in ASP.Net MVC

Answer 3

Because web apps have concurrency 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 4

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 is fits well with this mode of computation. Functional programming helps to reason about what to perform rather than how and when.

This actually complement 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 what you mean. You wou'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 introduce asynchronous web request to ease the development of AJAX application. As a consequence, EJB 3.1 have asynchronous method invocation to integrate with the asynchronous web layer. At the bottom with 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 to 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 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!

Answer 5

To stick to your question ...

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).

This is precisely the part where background concurrency (on the server) is needed sometimes, and preferable to an Ajax-spawned web thread:

• A background computation could be too long for the Session, so you can't use a web thread (you would timeout your Session).
• A background computation may not need to hold much information that is otherwise needed for that user, it may need much less context, which is good for freeing memory.
• Nightly batches might process huge database tables by chunks, and require exclusive access to these tables. Multi-threading might be required to bring computation-time within an acceptable duration (allowing other tasks to follow, or users to access the results after an acceptable duration). It is not uncommon to stop user interactions during a time-frame at night, and process some batches, and mastering the concurrency interactions at that time might be critical.

Answer 6

About all concurrency in web apps is based on multi-user experience. Often it's just "one process per user", with no common denominator and possibly connected only at database level, but apps like Flockdraw, usteream and other that group many users together in realtime, keep them interconnected and synchronized by multiple threads taking load of separate users but interfacing with each other actively in the realtime.