Is Task parallel library, PLINQ or Concurrent Collections used in Web Applications built with Asp.Net core Mvc or Razor Pages?

Question

I am beginner in C# , .Net core. So, I do have very limited knowledge over this advance topics (Task parallel library, PLINQ or Concurrent Collections). If my question seemed like idiotic, then I am extremely sorry.

I have developed small web apps using Asp.Net core MVC and Razor pages. I have used async and await in those web apps but never got an opportunity to use TPL or PLINQ or Concurrent collection. As Presently I am learning Multi threading and I am looking for opportunity to implement TPL, PLINQ or Concurrent Collections in my Web Apps.

So here are my queries,

1. Is Task parallel library, PLINQ or Concurrent Collections used in Web Applications built with Asp.Net core MVC or Razor Pages??
2. If it is used, so what are those situation where TPL, PLINQ are more suitable than async.
3. Is there any tutorials related this topic??

[Update]

If I used PLINQ or TPL or Concurrent Collection in utility Library or Repository Services will it be too much for my web apps or will it create deadlock or blocking in my Web App [.net core ]

Or I am making simple thing very much complex??

Thank you.

Answer 1

Is Task parallel library, PLINQ or Concurrent Collections used in Web Applications built with Asp.Net core MVC or Razor Pages??

The short answer is: No for PLINQ & multi-threading.

First, async/await are wrapped around Task class, which is part of TPL.

Second, it's considered bad practice doing parallelism and spin multiple worker threads in an ASP.NET (Core) application.

In ASP.NET Core you use TPL and async / await for truely async operation (network calls, I/O access (file access), database calls etc), where the application has to wait on an external hardware component to finish.

CPU bound tasks (calculations etc. running on one or multiple threads) arern't awaited in ASP.NET Core applications and just done on the main thread (in a "blocking" fashion).

ASP.NET (the legacy one) used to have its own thread pool for managing connections and ASP.NET Core just uses the default thread-pool for it. In legacy ASP.NET you would still have single thread exection per request, even if you use PLINQ fire off multiple tasks and await them. ASP.NET Core wouldn't.

Still, spinnig off your own tasks and threads is a bad idea. It may make your single threaded operation faster when having low number of requests (lower latency), but may make it unresponsible in high-request scenarios due to thread starvation and your application spending a lot of CPU time managing and switching between threads. It also interferes with the thread heuristics.

Also on thread starvation, your application won't accept any new requests. For that reasons CPU bound tasks are meant to be run syncronously. Running an CPU bound work via Task.Run alone gains you nothing. You free up the request thread while waiting for the task to finish, but since you spin up a new task, another thread is used to process it.

Its similar to when running parallel task. When you run to many per request, there is one point where you have to many tasks queued and to many requests and application stops accepting requests and the user get the dreaded "50x" http errors for your application not accepting new requests where as not spinning up many parallel tasks would allow you to take a much higher number of connections and queue them while the other tasks requests complete

Concurrency and parallel tasks are important for Desktop applications and awaiting them there makes sense (to not block the UI thread), even if its a single lengthy execution. Also, in a Desktop application you can be certain, that the application is only used by a single user, so using up as many CPU cores as possible to process a task quickly is a very good thing.

It just doesn't translate well, when you apply this to a sharerd application such as an ASP.NET Core application where an unknown numbers of users will interact with it.