我應該將我的操作方法轉換爲異步操作方法嗎？

Question

我有一個網站，用戶可以上傳PDF並將其轉換爲WORD文檔。

它的工作很好，但有時（每小時5-6倍）的用戶將不得不等待比平時多的轉換不會發生....

我使用ASP.NET MVC和流程是： - USER 上傳文件 - >獲得流和轉換它字 - >保存字的文件作爲臨時文件 - >回報用戶的URL

我不知道如果我有將此流量轉換爲asynchronous？基本上，我的流程是順序現在，但我有大約3-5每秒請求和CPU是雙核心和4 GB RAM。如我所知maxConcurrentRequestsPerCPU is 5000;也The default value of Threads Per Processor Limit is 25;所以這些默認設置應該超過罰款，對吧？

那麼爲什麼我的網絡應用程序有一些「等待」？是否有任何IIS設置我需要從默認修改爲其他任何東西，或者我應該去使我的同步方法轉換爲異步？

Ps：轉換本身需要1秒到40-50秒，這取決於pdf文件的大小。

UPDATE：基本上對我來說不是很清楚的是：如果用戶上傳文件並且轉換很長，那麼不僅當前請求「受到」是因爲這個？因爲下一個請求是獨立的，所以再做一次CPU調用和不同的線程，所以不應該在這裏等待，不是嗎？

Answer 1

有幾件事情必須在這裏明確定義。至少就我所能理解的而言，異步（hronous）方法和流程並不是一回事。

（使用任務，通常也利用異步/伺機關鍵字）的異步方法將在下面的方式工作：

1. 執行對線程T1開始，直到它到達一個AWAIT
2. 的（潛在）長操作不會發生在線程t1上 - 有時甚至不會在應用程序線程上，利用IOCP（I/O完成端口）。
3. 線程t1空閒並釋放回線程池，並準備好在需要時處理其他請求
4. 當（可能）長操作返回一個線程從線程池中取出時（甚至可能是相同的t1或，最有可能，另一個）和執行代碼的其餘部分繼續從上次伺機遇到
5. 的其餘代碼執行

有幾件事情，這裏要注意：

一個。客戶在整個過程中被阻止。線程等的最終切換僅發生在服務器 b上。這種方法主要是爲了減輕稱爲「線程匱乏」的不需要的情況。這並不意味着要加快客戶的總等待時間，並且通常不會加快整個過程。

據我所知，異步流程意味着，至少在這種情況下，在用戶請求轉換文檔之後，客戶端（即客戶端的瀏覽器）將很快收到響應，其中被告知服務器上已經啓動了這個可能很長的過程，用戶應該耐心等待，並且當前的響應頁面可能會提供進度反饋。

---

在你的情況下，我建議第二種方法，因爲第一種方法根本沒有幫助。

當然這並不容易。您需要模擬一個隊列，您需要有一個處理代理和一個驅逐策略（如果您不想要第二個代理，最有可能由同一個代理強制執行）。

這將沿着以下線路工作：

a。最終用戶提交文件，網絡服務器收到它 b。 Web服務器將其放入隊列並接收作業編號 c。 Web服務器向用戶返回一個帶有作業號碼的響應（假設一個帶有輪詢機制的HTML頁面，該頁面將定期從服務器接收進度） d。當代理得到機會（即完成其他工作）時，代理將開始處理文檔，並在共同的地方更新其狀態，以供網絡服務器選擇這些信息 e。 Web服務器將接收來自HTML響應的請求，詢問作業的狀態，並會發現作業已完成並提供下載鏈接或直接下載。

這可以在某些方面加以完善：

1. 而不是客戶端服務器的輪詢，websockets或長輪詢（例如SignalR既包括）可用於
2. 許多處理劑可以用來代替一個如果硬件配置有意義

---

隊列可以用簡單的RDBMS，萊姆斯茹來實現şanu有a nice article about this。