Is Parallel code good for web based applications? [duplicate]

This question already has answers here: Closed 11 years ago.

Possible Duplicate:

Using Parallel Extensions In Web Applications

Since CPUs aren't getting faster but are getting more cores, parallel is the way to 开发者_StackOverflow中文版go for better performance on desktop applications, however I am not sure if the same is true for web based applications.

Web servers already have to spin lots of threads to handle all of the web requests, so would coding your application in a parallel fashion (say for sorting, searching, etc algorithms) help the performance or could it actually hurt it?

I'm particularly using ASP.Net but I think this question is valid for any platform.

---

I would question the initial assumption. CPUs are getting faster. Per-core performance is improving, although not necessarily at the rate that it was.

Web applications tend to perform many of their front-end tasks sequentially ... that's not to say that some operations can't benefit from multi-threading, but it depends very much on the workload, how well it can be split. Operations like searching and sorting are best threaded on large datasets, which aren't overly common for web apps. In many cases - when large sets of data are involved - a database server will do, and thread, this bit before it reaches the web server.

It's much more common to find back-end processes, which are triggered by web requests, performing multi-threaded batch operations. They can often benefit very heavily from multi-threading by the batch and easily split nature of the work.

If your web application is heavily modular, a component based CMS for example, or an application which aggregates data from several sources, or a service which performs batch operations, then multi-threading may offer significant benefits ... but you're also amplifying the footprint for each request. Do you really want one web-request tying up 10 database connections? (for example)

Maybe you do. I'm not sure I would :)

---

I am going to make the assumption that any operation you are considering parallelizing needs to be completed synchronously(sorting, searching) : in which case I am not sure it will always mean better performance it could degrade performance. Below is my reasoning for why. Take for example an environment where your app is running on a server that hosts 20+ other web applications. If its all in one thread the server will process it at one go and return your results. If you split it in to parallel threads some of your threads might finish but some others could potentially be stuck behind threads from other applications. So total response time will be slower even though number of CPU cycles will probably be close to the same.

However, if your operation can be completed asynchronously(relatively heavy calculation, optimization algorithm for display) I would suggest looking at splitting it into multiple requests on the client side and firing of several ajax requests that would then be served by different web servers in parallel (in a load balanced web farm) and mashing the results together on the client side.

Hope that helps!

---

In case of utilizing servers CPU - it can be useful. But it's wrong practice to utilize user's pc cpu - it can be very dangerous.

PS I hope this article at msdn blogs will help you. [link]