How does the parallel library task bar scale on a terminal server or in a web application?

I understand that TPL uses processing queues for its tasks when I do things like Parallel.For and similar constructs.

If I understand this correctly, the design will spin a number of tasks, where everyone will begin to process the elements. If one of the tasks performs their selected elements, it will begin to steal items from other tasks that have not yet completed them. This solves the problem when items 1-100 are cheap to process and items 101-200 are expensive and one of the two tasks just sits idle until the other is complete. (I know this is simplified exaplanation.)

However, how will it scale on the terminal server or in the web application (if we use TPL in the code that will work in the web application)? Can we risk saturating the processors with tasks only because N instances of our application work next to it?

Is there any information on this topic that I should read? I have not found anything yet, but this does not mean that they are not there.

+2
source share
1 answer

You may be able to use TPL to improve I / O binding operations by moving to an asynchronous model. You can also improve request latency by leveraging the available unused processor capacity on a web server in low-load situations. You want to think about this very carefully, because under high loads, where the processors are already 100% used, adding more parallelism will reduce the bandwidth on the server.

This is discussed in the parallel extension group blog:

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

I suspect the same argument applies to Terminal Server applications.

+1
source

All Articles