一起使用InProc和Azure AppFabric高速緩存

僅需一點背景。我目前有一個託管Windows Azure的站點，有多個實例，而且AppFabric也是我唯一的緩存提供者。一起使用InProc和Azure AppFabric高速緩存

一切都很好，直到今天早上我的交通刺激。在實例變得超載並停止響應之後，一旦新實例開始，所有事情都會恢復正常。

但是我開始從AppFabric收到消息，說我被限制，因爲在給定的時間內請求太多。這是公平的，當然是給它下地獄。

爲了在將來避免這些消息，我計劃在非常短的壽命期內實施InProc緩存。因此，它首先檢查InProc，如果不去AppFabric，則不檢查數據庫。

ObjectCache cache = MemoryCache.Default; 

CacheItemPolicy policy = new CacheItemPolicy(); 
policy.AbsoluteExpiration = DateTimeOffset.Now.AddMinutes(5);

我的問題是

這是處理這種情況的最好方法是什麼？
這是干擾AppFabric緩存嗎？
我忽略的任何問題？

更新我只是想說，我選擇了上面的方法，而且運作良好。我只是將它用於一般數據存儲而不是會話狀態。具有會話狀態的MemoryCache在Azure上無法正常工作，因爲沒有服務器關聯（如下面的David所述）。

更新16-03-2012 在意識到顯而易見後，我也在大多數頁面上禁用了SessionState。我的大部分頁面都不需要它，因此這會迅速減少我在重負載下緩存的呼叫。我也爲大多數頁面禁用了ViewState，只是爲了稍微快一點的頁面加載時間。

來源

2012-03-08 Adam Pedley

我發現你不應該將InProc與Azure一起使用，尤其是對於具有多個實例的角色。您不保證具有在同一實例上跨請求訪問相同進程的上下文。 – 2012-03-08 05:08:58

嗨格倫。感謝您的迴應。我知道InProc在任何實例中都不一樣，但是我更多地談論了使用InProc作爲每個實例的臨時緩存，這些緩存在幾分鐘後過期，只是爲了減輕AppFabric的壓力。我還認爲，即使每5分鐘擦一次，重負載下的InProc速度也會更快。 – 2012-03-08 05:15:17

您是否考慮監控請求並在高峯時間以編程方式啓動新實例？ – 2012-03-08 05:16:46

試試這個：http://msdn.microsoft.com/en-us/magazine/hh708748.aspx

來源

2012-03-08 11:40:15 RichBower

感謝@RichBower這剛剛證實我可以使用InProc與AppFabric緩存。它運作良好。它確實減輕了AppFabric在重負載下的命中率。 – 2012-03-09 06:59:50

我做的一件事就是使用HttpContext.Items。這僅適用於每個請求緩存，但取決於系統的性質可能很有用。

來源

2012-03-08 05:44:08 Craig

謝謝克雷格。我爲所有用戶緩存了很多項目，而不是那麼多的單個會話。 – 2012-03-08 05:56:46

我不會建議INPROC，由於沒有服務器的親和力。

使用Windows Azure緩存來避免小時配額限制的一個選擇是提高緩存大小。幸運的是價格並沒有線性增長。例如：128MB爲45美元，256MB爲55美元。因此，一種選擇是將您的緩存提升到下一個尺寸。由於無法實時監控緩存使用情況，因此您需要通過性能計數器來監控計算性能。

另一種選擇是將會話狀態轉移到SQL Azure，它現在是Azure 1.4（2011年8月 - 有關詳細信息，請參見this article）的官方支持的會話狀態提供程序。使用最新的SQL Azure pricing updates，如果數據庫保持在100MB以下，那麼每月費率爲4.99美元，而不是原始的9.99美元基準。它每天分攤一次，所以即使你有瞬間尖峯並進入1 + GB範圍，你仍然有一個相當實惠的緩存倉庫。

來源

2012-03-08 13:07:43

謝謝大衛。我主要使用緩存來處理數據庫中的項目，而不是會話狀態（儘管我當然也使用了一些會話狀態）。我在AppFabric上保留了會話狀態，但爲緩存的數據庫項目完成了MemoryCache（inproc）。在重負載下，它會迅速降低AppFabric的點擊率。然而，一旦流量進一步增加，我將不得不將您的建議升級到新的水平。 – 2012-03-09 06:58:58

另一種可能的解決方案是使用粘性會話這樣的例子：

http://dunnry.com/blog/2010/10/14/StickyHTTPSessionRoutingInWindowsAzure.aspx

來源

2012-03-08 14:52:40 Tom

是否使用高速緩存您的應用程序，或兩者都提供SessionState的存儲或者一般的數據存儲？這並不完全清楚，因爲InProc通常引用SessionState，但示例代碼看起來不像SessionState。

假設您正在存儲可以在本地安全緩存的數據，那麼我建議您查看AppFabric本地緩存。它基本上是你想要的，不需要編寫任何單獨的代碼（我認爲...）。

否則，如您所述使用MemoryCache是一種可行的方案。我已經在我的應用程序中完成了這項工作，只需要小心避免緩存不一致問題。

根據您的應用程序，您可能還希望通過將數據存儲在HttpContext.Items集合中來實現每個請求緩存。當您的代碼的不同部分可能在單個請求期間請求相同的數據時，這會很有幫助。

來源

2012-03-08 18:29:15

使用本地緩存不需要更改訪問緩存的方式，只需要如何初始化即可。如果你正在閱讀你的配置文件，它只是一個設置（http://msdn.microsoft.com/en-us/library/ee790816.aspx），或者它是DataCacheFactoryConfiguration的一部分，如果你在代碼（http ：//msdn.microsoft.com/en-us/library/microsoft.applicationserver.caching.datacachefactoryconfiguration.localcacheproperties（v = ws.10）.aspx） – knightpfhor 2012-03-08 20:18:18

感謝您的回覆@breischl，您正確的是我正在使用SessionState和我的應用程序的一般數據存儲。我現在只想做一般數據存儲的本地緩存。這是很容易實現的，因爲我的所有緩存都經歷了1個類，我在做了這些努力後，第一次將我的本地緩存升級到AppFabric :) – 2012-03-09 07:04:19

感謝評論@knightpfhor，我選擇了MemoryCache無論如何，因爲我不想搞亂所有與Sessionstate有關的緩存。我不希望會話狀態被存儲在InProc中。感謝鏈接，當然值得了解。 – 2012-03-09 07:07:08

一起使用InProc和Azure AppFabric高速緩存

回答

相關問題