在MVC/WebApi應用程序中將異步與手動啓動任務混合是否合適？

我正在構建一個WebApi應用程序，該應用程序將託管在Azure網站中，並在適當情況下使用async調用。但是，要求我使日誌記錄發生在與調用方法不同的線程中，以便繼續處理實際業務邏輯，同時某些「工作任務」處理日誌記錄。在MVC/WebApi應用程序中將異步與手動啓動任務混合是否合適？

一個示例場景是這樣的：

請求進入async行動 - >電話await businessComponent.ProcessAsync(args) - 同步_logger.Log(message, args)>電話 - >創建new Task(() => FormatAndWrite(message, args)，設置task.ConfigureAwait(false)，來電task.Start()

所以我希望有人經驗更豐富與async/await和方式ASP.NET處理async/await告訴我他們是否看到上述解決方案的主要問題？這是否可以在處理實際業務邏輯請求時節省時間？

來源

2015-02-24 IWriteApps

這只是一個可接受的方法，如果可以偶爾錯過日誌。 – 2015-02-24 16:16:57

這是因爲在傳入請求完成並返回之前，FormatAndWrite的執行可能不會執行？ – IWriteApps 2015-02-24 16:32:00

間接，是的。 ASP.NET將偶爾回收您的應用程序，但如果有請求正在處理，它將不會回收。 – 2015-02-24 16:48:10

是的。它可以通過使用多線程處理它來縮短特定的請求（假設您的業務邏輯至少有一些CPU綁定工作要做）。

但是，通過對每個請求使用多個線程，您可以使用相同數量的可用線程同時處理較少的請求。所以這是一個折衷。

如果目標是到工作卸載到ThreadPool使用Task.Run的明確，而不是new Task(...).Start並確保您await它離開async處理請求之前進行。 ASP.Net中的後臺任務可以在您不知情的情況下停止。

來源

2015-02-24 16:11:30 i3arnon

看到的東西是我試圖研究這一點，並遇到了一些文章，指出了3個問題，導致我問我的問題：1.只有使用等待，如果有明顯的優勢，因爲等待在引擎蓋下昂貴（這對於我們的日誌記錄來說太過分了）。2.不要在ASP.NET中將Task.Run與Task.Run混爲一談，因爲Task.Run顯然會向ThreadPool請求一個它不期望創建的新線程它不是一個新的請求進來。所以我不知道什麼是正確的... – IWriteApps 2015-02-24 16:13:59

@IWriteApps 1.我懷疑'等待'比這個阻塞IO操作更昂貴。 3. ThreadPool通常不會創建線程。這是一個已經創建的池。只有在用完它們時纔會創建新線程。 – i3arnon 2015-02-24 16:54:11

@IWriteApps真正的問題，正如我理解與Task.Run一樣，正如Stephen Cleary所述，如果你的應用程序當前沒有處理請求，它可以被回收。通過「等待」從Task.Run返回的任務，您可以保持該請求存活。您也可以不等，但意識到您可能會丟失日誌。 – i3arnon 2015-02-24 16:57:21

在MVC/WebApi應用程序中將異步與手動啓動任務混合是否合適？

回答

相關問題