IIS和單線程應用程序

Question

我想知道IIS托管的單線程.NET應用程序中的請求/響應模型。 例如，如果它是一個單線程讀取大文件的WebAPI應用程序，則對其進行處理（對內容進行一些字符串操作）並在API響應中返回其處理后的內容，為便於論證，我們假定它采用了10分鍾處理文件。

現在，我了解到ASP.NET IIS映射在這里是多線程的：

ASP.NET如何是多線程的？

那么，如果我在一分鍾內向同一個API發出20個請求怎么辦？

1. 呼叫者2等會發生什么？ 在IIS接收之前等待10分鍾？
2. IIS在哪里跟蹤傳入的請求？

Answer 1

默認情況下，IIS同時處理請求。 如果您沒有主動采取任何措施來阻止它，則如果同時有2個請求到達，則將同時在2個線程上開始處理同一文件。

如果不需要並發處理，則可以使用同步原語之一，例如lock(...)或互斥鎖。 然而; 如果處理需要10分鍾，您確定要作為Web請求的一部分嗎？ 可能會有更好的選擇。

Answer 2

無需進行任何調整，IIS將像其他任何服務器一樣並發處理請求。

1. 如果請求隊列大小，請求超時和線程池大小將設置為適當的值-請求2將是在IIS請求隊列中花費10分鍾后的進程。

2. 沒有持久性。 只有RAM。

這是一種不尋常的情況-等待如此長的請求完成，然后在一段時間內返回響應。 從系統設計的角度來看，在后台作業管理器中將此計算排隊或在可能的情況下緩存結果，立即返回數據而不是等待幾分鍾就有意義。

我想到的另一個選擇如下所示：

1. 設置一個后台作業以一一處理文件。
2. 將文件發布到服務器后，返回表示其身份的令牌。
3. 創建一個單獨的端點以使用文件身份。 服務器應返回已處理結果或消息，指示文件在隊列中並正在等待處理。

Answer 3

這是一篇很好的文章，描述了HTTP請求在到達您的代碼之前傳遞的所有層：)每個層都有自己的配置和限制。

請注意，.net線程池的增長相當緩慢，每秒增加2個線程。 如果您的控制器中有同步阻止代碼（使用鎖或互斥鎖）並將100個請求推送到服務器，則您的代碼將僅在45秒內處理最后一個請求：將立即處理10個請求（考慮到默認線程池大小） ，那么線程池將增長（緩慢）並在45秒內處理所有剩余的90個請求（向該池中添加2個線程）。