Concurrency in web applications

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.

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.

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!

Yes, in high performance server and long running tasks

Check out Async controllers in ASP.Net MVC

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.

To my understanding, the question arises from the complication of two different implications of the concept concurrency: the concurrent service of a web site to user requests (macro level) vs. the concurrent execution of two programs/processes/threads (micro level).

They use both the same word concurrent, yet the former is homogeneous, if we simply assume the server provides just one service, and there is no interaction/commonage between the macro-level services provided to different users. Even if the services to different users go to the data storage level and thus contend for IO resources, that's more of a problem of the micro-level: two queries/writes race against each other for common resources. As an abstraction the services provided to users are always homogeneous, therefore concurrency functionality/libraries provided by platforms (you mean Java, .Net, and etc. I guess) has nothing to do with web apps, but with only the micro operations far beneath them.

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.

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.