在我們仍在開發的項目中，我們注意到訪問我們的ASP.NET Web API服務時突然出現延遲。我們使用真棒Mini Profiler指出，這些延遲是由於與Azure數據緩存（預覽）服務的連接斷開而必須重新建立時引起的。這個過程大約需要3.3秒。重新連接後，從緩存中獲取對象需要1.4 ms。連接到Azure緩存服務大約需要3.3秒
當我將maxConnectionsToServer從1增加到20時，我注意到了另一件事。如果我不向Web API發出1或2分鐘的請求（通常是連接斷開時），然後開始撥打電話，接下來的20個請求會延遲3.3秒，這就是連接池的工作原理，我猜（round - 從池中取出連接）。
Web API和Caching服務都位於美國東部地區，我們禁用了本地緩存，禁用了SSL，啓用了自動發現功能。
所以，我想知道如果我們的配置有什麼問題，或者這是一件事情，因爲Azure緩存仍在預覽中？
任何信息將被評估。
謝謝！
聽起來好像您的共享緩存由於不活動而被卸載。測試此方法的一種方法是將角色內緩存添加到現有服務（如果可用）並將緩存使用情況交換到此新緩存。角色緩存描述爲here。
一旦高速緩存移出共享產品，等待1-2分鐘的空閒時間並重試連接，則延遲不應存在。
假設您想在隔離問題後堅持使用共享緩存選項，我目前唯一的解決方法是運行一個後臺任務，該任務將週期性地ping緩存以保持其活動狀態。
如果您正在運行完整的Web角色，則可以在應用程序啓動時啓動後臺任務。
如果您通過移動服務部署，則可以通過預定作業運行「ping」。您可能遇到的唯一問題是預定作業的最短時間爲1分鐘，這可能不夠積極，無法保證您的緩存在100％的時間內保持活躍狀態。
我沒有看到指向你做錯任何事情。這可能是Azure真正遇到問題，快速獲取緩存連接並運行。根據幾個最佳實踐文檔和MSDN帖子，您希望增加與緩存的連接數量，以便將故障轉移到活動連接，這些配置更改可有效完成。
嘗試確保您的緩存訪問器是一個靜態對象（另一個MSDN建議），這可能是一個長鏡頭，但可以考慮使用Sliding Window選項來訪問對象，並查看它是否不僅告知對象存儲的倒計時重置，還會提示緩存服務重置連接。
感謝您的回覆。我們不使用共享緩存服務，而是使用新的Azure緩存：http://msdn.microsoft.com/en-us/library/windowsazure/dn386094.aspx –
我應該澄清 - 您選擇的層次決定了您的緩存是共享的或專用的。如果您正在基本層下運行，則可以在共享硬件上運行，如果您選擇了在專用硬件上運行的標準層或高級層。層詳細信息在這裏：http://msdn.microsoft.com/en-us/library/windowsazure/dn386114.aspx。 – MOverlund
試用標準產品 - 同樣的事情。連接需要約3秒鐘才能建立。 –