異步VS水平縮放

我工作.NET客戶端消耗一個REST API（JSON）上。客戶端是高流量和可觀的用戶交互的web應用程序異步VS水平縮放

當寫周圍的外部REST API的包裝我試圖決定

如果我應該做的API異步進行的所有通話？這將從UI到API的所有方式，如此處所述http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html。這將幫助我實現理想的性能，但是當任務等待完成時，我將不得不找出一種處理UI的方法。
或者這是否是一種矯枉過正？我只使用同步/順序代碼？我仍然可以通過水平縮放應用程序來獲得（某些）性能？

我渴望瞭解什麼是從客戶端調用外部REST API（如果有的話），以及如何在UI的人們不要使用異步的情況下處理的首選方式？

2015-06-09 nesh_s

同時運行多少個請求？或者，您需要每秒處理多少個請求，以及他們需要多長時間？ – usr

在最繁忙的時期（出售），典型的負載將是每5分鐘2700個獨特請求或每分鐘500個左右。在銷售期間的任何時候，我們預計有170個在線用戶。至於他們需要多久，其基本上是一個庫存頁面，用戶將看到最新的庫存，所以它只是一個數據庫讀取API的操作，返回的記錄將在每次調用150個區域。對不起，如果這不能回答你的問題。謝謝 –

所以，你必須在一個繁忙的時期大約每秒10個請求。這本身不需要異步IO。假設每個請求有1個線程爲1個線程。 10條主題是沒有什麼。

有一個特殊的情況，是：如果你所呼叫有時後端服務需要較長時間來響應（錯誤，過載，索引重建，...）？如果需要30秒的響應或超時，這意味着有300個請求正在運行。這對於默認的線程池設置來說太多了。這將通過池耗盡來有效關閉整個應用程序，直到請求被清除。

你可以做兩件事情：

使用異步IO所有大批量的行動。
減少超時和具有負載斷路器用於飛行的請求的數量。例如：

。

SemaphoreSlim sem = new SS(50); //max 50 in-flight 

//... 

if (!sem.WaitOne(TimeSpan.Zero)) 
throw new Exception("Load limit exceeded");

兩者同樣安全且表現良好。不要認爲異步IO會導致您的IO變得更快。

信號燈解決方案需要更少的體系結構的變化，但它需要許可下降請求。這些請求不會以高可能性完成。

來源

2015-06-09 14:43:43 usr

感謝您的回覆。說得通。我在這個API調用之上有一個斷路器實現，超時和閾值是我們在裝載到一個合理的數字時配置的。在等待請求完成時如何處理用戶界面的任何想法？我可以使用什麼策略？假設用戶在庫存頁面上應用了一些過濾器，並且部分工作流程是將過濾器應用於最新的數據集。在這些情況下，我如何處理異步調用？ –

我沒有看到您遇到的特定問題。爲什麼用戶界面在超載的情況下需要特殊處理？顯示錯誤。 – usr

異步VS水平縮放

回答

相關問題