異步功能有什麼好處嗎？

Question

Azure函數允許我編寫在特定條件下執行的C＃/ F＃（以及更多）函數。這些函數可以是異步的（通過返回一個Task）。

關於天青功能的一件很酷的事情是，它們會根據負載自動放大。 「經典」服務器上異步/等待模式的一個很酷的事情是，您可以更好地利用核心，以便處理更多請求。

由於azure函數自動縮放，對於編寫異步函數有沒有什麼好處？

Answer 1

您會在Azure函數中使用async，這與您在其他任何應用程序中的原因相同。對於阻止可能長時間運行的外部I/O的操作，它將更有效地利用資源。 Azure函數完全支持運行時核心中的異步，所以正確使用時，它將允許單個函數應用程序獲得更好的並行性和更好的吞吐量，因爲線程不會被阻塞等待I/O，並且可用於處理更多請求/觸發器。

如果您的功能應用程序在經典SKU上運行，那麼您需要爲Always On實例付費，因此很明顯，您希望儘可能高效地使用資源。

當在動態SKU中運行時，我認爲您的問題是，如果我們只根據需要擴展功能，那麼誰在乎他們是否有效地使用資源？我仍然會說，最好讓你編寫你的函數，讓它們儘可能高效地運行。這樣，當真正需要時，我們只能將您擴展出來，並且在我們旋轉它們時最小化新實例的冷啓動時間。

Answer 2

當您在動態計劃中對Azure函數使用異步時，您仍然受益匪淺。這是因爲你的應用消耗更少的資源（特別是線程），使其更加高效，因此成本更低。一些例子浮現在腦海：

• 上下文切換：當運行高併發工作負載，你最終會分配給你的函數應用程序實例線程的數量較多。這大量的線程將導致昂貴的上下文切換，這會增加功能執行的延遲並因此可能增加您的賬單。
• 線程池增長：如果您有很多線程並需要添加更多線程，由於CLR如何抑制線程池的增長，這可能會給函數執行增加額外的延遲。喬恩·科爾有這個here的一個很好的說明：

一旦現有的（忙）的線程數命中線程的「最低」號，線程池將油門在這是速度注入新的線程每500毫秒一個線程。這意味着如果你的系統需要一個IOCP線程的工作，它會很快處理這個工作。但是，如果突發工作超過配置的「最小」設置，則在處理某些工作時會有一些延遲，因爲ThreadPool會等待發生以下兩件事之一：1.現有線程可以自由處理工作2.現有的線程在500毫秒內沒有空閒，所以創建了一個新的線程。

• 內存使用：多個線程意味着更高的內存使用情況。今天，你爲內存使用量的上限支付一筆固定的金額，但如果這種變化將來基於實際消耗的內存而變化，那麼你將爲這種不必要的內存開銷付出更多的金錢。

如果它不是很多工作，我強烈建議您利用函數中的異步模式。除了上面提到的原因外，最好不要對平臺的容量或動態規模邏輯的效率做太多假設，因爲不準確的假設可能最終導致成本增加。 :)