Azure服務結構 - 分佈式計算代碼示例Monte Carlo仿真 - 性能問題

Question

聽過最近的azure播客（特別是關於在azure上構建低延遲金融系統的播客）並閱讀所有關於服務結構的宣傳，我決定嘗試修改「分佈式計算代碼示例蒙特卡洛模擬」模式適合我的需求。

我的場景是： 使用一個簡單的（計算明智的）基於monte-carlo的模型，用一個給定的起始狀態運行10k個全運動比賽模擬的一個請求。

我第一次嘗試是：

• 1 *接收匹配的啓動狀態，並將其轉發到10k +任務演員，相關聚合的actorId

  沿着有狀態的「處理器」演員

  • 10K + * StateLess'Task'Actor運行1次模擬並將結果傳遞給其聚合器Actor。仿真時間小（〜2毫秒）

  • 100 *有狀態「聚合器」行動者聚集接收到的模擬和傳遞到finaliser演員所計算的最終結果

• 1 *「Finaliser」演員

運行在僅使用任務我開發框上面的花費< 100毫秒，但上面的設置（在開發計算機上運行的本地集羣）把50secs和更多！

調試通過一個潛在的原因，我發現是處理器角色發送初始任務所需的時間量，所以我想知道什麼樣的開銷在調用服務結構（我想各種命名當我打電話給演員的方法時，服務電話正在發生）以及這種緩慢是否可能是由於這一點以及我的任務數量？

要消除其他可能我做了以下，發現只有在總時間非常小的差異：

• 的所有演員無國籍，保證國家管理不增加開銷。
• 在處理器中創建所有ActorProxy，並存儲它們的引用以備將來調用，以確保Actor Activations不會引起問題。

有沒有人有什麼建議可以從這裏走，還是有人試圖實施類似的東西？

謝謝， 亞歷克斯

Answer 1

我會公佈這是一個評論，但我還沒有足夠的信譽爲保證！如果您在Service Fabric的文檔中參考this page，請查看文章下方的註釋，特別是2015年6月前後「tom」開始的評論跟蹤。他的性能差（每秒約20次操作），有狀態演員，這似乎被認爲是未來改進的一個領域。他們強調對非變異方法使用只讀屬性來顯着提高性能。Abhishek Ram還包括一些說明和information on relevant performance counters的鏈接，可能有助於排除故障。

您注意到您嘗試使用無狀態的演員而對性能影響很小。我會進一步指出另一個用戶使用只讀方法報告其他用戶每秒對單個演員實現每秒2k +操作的評論路徑，我希望這些方法類似於無狀態演員方法。也許可以將性能計數器的信息與此進行比較，以瞭解您的性能與評論中的稍微微不足道的示例的匹配程度。