1

I am wondering about the request/response model in a single-threaded .NET application hosted in IIS. For example, if it is a WebAPI application which is single-threaded to read a large file, process it(do some string manipulation on the contents) and return it processed-contents in API response and for sake of argument let's assume that it takes 10 minutes to process the file.

Now, I read that ASP.NET IIS mapping is multi-threaded here:

How is ASP.NET multithreaded?

So what happens if I make 20 requests to the same API within a minute?

  1. What would happen to caller #2 and so on?? Wait for 10 minutes before IIS picks it up?
  2. Where does IIS track incoming requests?
JuanR
  • 7,405
  • 1
  • 19
  • 30
Lost
  • 12,007
  • 32
  • 121
  • 193
  • By default, whatever runs in IIS is multi-threaded. – Mark Cilia Vincenti Jul 23 '19 at 20:38
  • If your request takes more than a short handful of seconds to process, it doesn't makes sense to do that work directly in a web app. Instead, move it to a background process. Clients can initiate the work by hitting your API, then they can poll for a result (or use webhooks or other techniques to notify them). – mason Jul 23 '19 at 20:56

3 Answers3

1

By default IIS processes requests concurrently. If you don't do anything actively to prevent it, you would start processing the same file on 2 threads concurrently, if 2 requests arrive at the same time.

You can use one of the synchronization primitives such as lock(...) or a mutex if concurrent processing is not desired. However; if it takes 10 minutes to process, are you sure you want to do it as part of a web request ? There could be better alternativees.

driis
  • 161,458
  • 45
  • 265
  • 341
1

Without some tweaks IIS will process requests concurrently as any other server would do.

  1. If request queue size, request timeout and thread pool size would be set to appropriate values - the request #2 would be processes after spending 10 minutes in IIS request queue.

  2. No persistence. Only RAM.

It is kind of unusual scenario - to wait for such long requests to complete and then return a response in a while. From system design perspective is makes sense to queue up this calculation within a background job manager or cache the results when possible, returning data immediately rather than waiting for many minutes.

A bit another option which comes to my mind looks as follows:

  1. Setup a background job for processing files one-by-one.
  2. After POSTing a file to the server return a token representing its identity.
  3. Create a separate endpoint to consume file identity. Server should return either processed result or message indicating the file is in the queue and is waiting to be processed.
Artyom Ignatovich
  • 591
  • 1
  • 3
  • 13
  • 10 minutes to process a job is a hypothetical scenario to exaggerate the timing and serve it as a platform to discuss how different threads would be served. In a larger scheme of things, I would definitely agree with you that it should be served in a message-queue or a background process of it is going to take such a long time to process it. – Lost Jul 23 '19 at 21:26
  • I used [Hangfire](https://www.hangfire.io/) for similar purpose, [here](https://www.reddit.com/r/dotnet/comments/8y8kuy/best_way_to_schedule_tasks_in_web_application/) is a discussion with other alternatives – fenixil Jul 30 '19 at 04:17
0

Here is an good article which describes all layers that HTTP request passed before it comes to your code :) Each layer has its own configuration and limits.

Please note that .net thread pool grows rather slowly, it adds 2 threads a second. If you will have synchronous blocking code in your controllers (use lock or mutex) and push 100 requests to the server, your code will handle last request only in 45 seconds: 10 requests will be handled immediately (considering it a default thread pool size), then thread pool will grow (slowly) and will process all remaining 90 requests in 45 seconds (adding 2 threads to the pool).

fenixil
  • 2,106
  • 7
  • 13
  • What is overall limit to #of threads that IIS can spin? Or is there any? – Lost Jul 30 '19 at 04:35
  • Define IIS? Your application is limited by memory and number of descriptors to spin up the threads. For thread pool you may use [ThreadPool.GetMaxThreads()](https://learn.microsoft.com/en-us/dotnet/api/system.threading.threadpool.getmaxthreads?view=netframework-4.8) to determine a capacity for your website. W3WP has its own [configuration](https://learn.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/7w2sway1(v=vs.100)), HTTP.sys's configuration is [here](https://support.microsoft.com/en-us/help/820129/http-sys-registry-settings-for-windows) – fenixil Jul 30 '19 at 04:51