views:

266

answers:

5

I'd like to hear some opinions as to what role, if any, parallel computing approaches, including the potential use of the parallel extensions (June CTP for example), have a in web applications. What scenarios does this approach fit and/or not fit for?

My understanding of how exactly IIS and web browsers thread tasks is fairly limited. I would appreciate some insight on that if someone out there has a good understanding. I'm more curious to know if the way that IIS and web browsers work limits the ROI of creating threaded and/or asynchronous tasks in web applications in general.

Thanks in advance.

+3  A: 

Well, web-servers present an interesting challenge in that they are already highly threaded, servicing parallel requests. So on a busy site, you can't rely on being able to steal lots of cores for your ends. Of course, if you only expect light traffic, and your site requires lots of crunching (data processing etc), then you might be able to get some savings.

I would expect Parallel Extensions to work better at the client, or dedicated service apps, where you can reasonably expect the cores to be available for your [ab]use.

Marc Gravell
A: 

Your humble web server is generally best suited to serving up static content which it can cache. I really doubt its suitability for parallel processing (except as a pure experiment out of interest).

Some clarity after the comment: My original point is not that IIS does not process in parallel. My point is that "parallel processing" is not really just serving up web applications. My understanding of a parallel processing problem is one big computing problem that is broken down into smaller parts, which are then executed in parallel on more tham one processor.

Executing multiple threads on the same processor is actually less efficient for this type of problem than running single threaded. Can IIS be kludged into parallel processing? You bet. Is it the ideal platform? No.

Bork Blatt
IMO IIS+ASP.NET is much more than just a web server, it's more like an application server with web front-end. As such, parallel processing is applicable here as well.
Mauricio Scheffer
I still disagree... you're saying "this type of problem", as if the problem was serving pages. This question is about web applications, not IIS itself.
Mauricio Scheffer
A: 

I would not concern myself too much with parallel extensions in web based applications. If you do have several remote requests in a page (db calls, or remote web services), it may be worth looking into.

Web based applications are already highly parallel. And you don't gain much from parallel execution inside server side methods. The one exception is with regards to multiple remote requests (dbms or web-service) within the server-side code, where most of your time is spent waiting on remote resources, may as well have your waiting time on the multiple requests operate in parallel as opposed to serializing the requests.

For example, I have a portal page that I am planning on making all the db calls and webservice calls in separate threads, and shoving the results in httpcontext's items collection for consuming in the user controls later in the page life-cycle. Using ajax techniques can be an option here as well though.

Tracker1
A: 

In the case of display logic there probably won't be a ton of benefit to using PE since these functions are often fast and straight forward for the app to handle. Leave it to Microsoft to develop the parallel architecture in IIS.

Where you will notice benefits however is in cases where you might have long running reports or business logic that takes a substantial time to execute. In these cases using PE can dramatically speed up the application and combined with caching provide the end user with a much more powerful user experience.

One example is where we run complicated reports that iterate through large amounts of data and need to parse it or do some sort of function against it. Using PE can take something that takes 20mins and make it take a few minutes where the business logic is running in the web app. (Ignore databases since the DB is probably already threaded). We have a pre-order function that tells us what to buy from suppliers and it went from 5 hours to 30 mins after threading it so there are tangible benefits to threading/PE.

The second scenario is where you might need to parse complex data for each customer. While the app request may execute on different thread, there may be other idle threads that you can take advantage of and leverage their power. Using PE for this purpose makes sense.

Middletone
A: 

You might be able to use the TPL to improve I/O bound operations by moving to an asynchronous model. You might also be able to improve request latency by making more use of the available unused processor capacity on a web server in low load situations. You want to think about this pretty carefully as under high loads where the processors are already 100% utilized adding more parallelism will reduce throughput on the server.

This is discussed on the Parallel Extensions Team Blog:

Using Parallel Extensions for .NET 4 in ASP.NET apps

Ade Miller