50GB HttpRuntime.Cache持久可能嗎？

我們有一個ASP.NET 4.0應用程序，它從數據庫中繪製一個複雜的數據結構，該結構需要12個小時才能進入內存數據結構（稍後存儲在HttpRuntime.Cache中）。數據結構的大小正在迅速增加，如果應用程序重新啓動，我們無法繼續等待12個小時以將其存入內存。如果您想更改web.config或導致重新啓動的Web應用程序中的任何代碼，這是一個主要問題 - 這意味着應用程序可以使用前的漫長等待時間，並阻礙開發或更新部署。50GB HttpRuntime.Cache持久可能嗎？

數據結構務必在內存中以使網站可用的速度工作。在內存數據庫中，如memcache或Redis與HttpRuntime.Cache相比速度較慢，並且在我們的情況下不起作用（內存中的db必須序列化put/get，而且它們不能相互引用，所以它們使用的鍵是查找 - 性能下降，加上大量密鑰，性能快速下降）。表演是必須的。

我們希望做的是快速轉儲程序結束前的HttpRuntime.Cache到磁盤（在重新啓動），並能夠立即加載它回來時，應用程序再次（希望開始幾分鐘內，而不是12+幾小時或幾天）。

內存中的結構大約爲50GB。

有沒有解決方案？

來源

2011-09-17 Stephen

只要你的機器有足夠的內存（在你的情況下64GB +）和體面的磁盤陣列應該沒問題...不知道你還在尋找什麼樣的重新設計，看起來不像是一個基於問題的選項。 –

你所要求的有點違背邏輯。爲什麼你想要與整個50GB數據結構交互？對於這個更好的數據庫結構或適當的報告方法來說，這是理想的解決方案嗎？ – slugster

@Stephen解決方案是讓您贏得簡單的自定義緩存並使用它。最容易的是創建一個平坦的新表，並且包含所有複雜的數據結構，並在必要時更新它，我認爲你走錯了路。 – Aristos

內存數據庫等內存緩存或Redis的是比較緩慢的HttpRuntime.Cache

是的，但他們都非常快相比12+小時的自旋向上。就我個人而言，我認爲您在強制加載50 GB結構時採取了錯誤的方法。只是一個建議，但我們使用HttpRuntime.Cache作爲多層緩存策略的一部分：

本地緩存檢查等第一
否則的Redis用作緩存的下一層（這是比快的基礎數據，持久性，且支持多個應用服務器的）（然後本地高速緩存被更新）
否則，底層數據庫被擊中（然後兩者redis的和本地高速緩存被更新）

點在加載時，我們不需要需要記憶中的任何東西 - 它在需要時被充滿，從那時開始很快。我們還使用pub/sub（redis的禮貌）來確保提示緩存失效。最終的結果是：它足夠快，寒冷時，溫暖時速度非常快。

基本上，我會看什麼，避免需要的50GB數據之前，你可以做任何事情。

如果這個數據是不是真的緩存，但你數據，我想看看序列化在一個適當的對象模型。我會建議protobuf-net（我偏袒作者）作爲這裏的強大候選人 - 非常快速和非常小的輸出。

來源

2011-09-17 08:48:34

50GB HttpRuntime.Cache持久可能嗎？

回答

相關問題