異步DataCache API（.NET）

我使用的是Windows Azure緩存Nuget包的一部分的DataCache API，我想知道爲什麼沒有辦法對組成方法進行非阻塞調用。我錯過了什麼嗎？我知道這些通話的延遲時間會很短，但如果您不使用本地緩存設置，它仍然是網絡通話。異步DataCache API（.NET）

建議，想法？

謝謝！

來源

2013-02-26 MSDev23

我能想到的最好的是，那些實現特定庫的人不熟悉異步和任務。聽起來令人震驚。 – Arash 2013-10-22 09:57:30

如果你想明白爲什麼圖書館是這種方式，那麼我會讀一讀this article關於暴露同步方法的異步包裝。 TL：DR;想要實現異步，可伸縮性和響應能力有兩個不同的原因。如果它對前者有幫助，你實際上只需要一個異步版本的方法，後者可以留給API的使用者，因爲它很容易。

編輯：這似乎人們已經錯過了我的意圖在這個答案，所以我會嘗試添加一些更多的澄清。

是的，緩存客戶端可能會進行網絡通話，MS正試圖讓所有人都以非阻塞的方式進行所有網絡通話，以便應用程序保持響應。然而，這是一個緩存，它的設計非常快速。如果向緩存發出請求並且該項目不在本地緩存中（according to Scott Guthrie），則響應應該耗時1ms。鑑於響應速度如此之快（如果您使用本地緩存，速度會更快），它們可能會通過創建在後臺運行它的任務而增加更多開銷。

來源

2013-02-27 09:46:04 knightpfhor

增強的可伸縮性正是我尋找針對緩存的非阻塞調用的原因。我不希望我的實例花費大量的時間等待I/O。我知道，在與緩存（而不是數據庫）進行通信時不那麼擔心，但正如我在第一篇文章中提到的那樣，它仍然是一個網絡調用。 – MSDev23 2013-02-28 12:46:57

文章的要點是，圖書館的實施者不能（或者根本沒有想到）以某種方式來實現這種調用，而這種方式如果是異步的，則會更具可擴展性。如果它仍然是你的問題，那麼你可以很簡單地編寫你自己的異步包裝器作爲擴展方法。然而，在深入研究這個路徑之前，我會分析你的代碼，添加一個異步包裝器會增加一個性能問題，在這種情況下可能不合理。特別是如果你使用本地緩存，在這種情況下，沒有網絡電話。 – knightpfhor 2013-03-01 01:25:17

@knightpfhor：在已經同步的API之上添加一個異步包裝並不會使它變得更好，更糟糕的是，因爲一個線程已經被IO阻塞了，並且你正在增加上下文切換的開銷，創建任務等等。 MSDev23問的是爲什麼在API中不存在本地異步調用，因爲它不會首先阻塞IO的線程。 – 2013-09-10 18:01:48

異步DataCache API（.NET）

回答

相關問題