TL; DR：可能更快：訪問靜態局部變量，訪問存儲在HttpRuntime.Cache中的變量，或訪問存儲在memcached中的變量？ASP.NET緩存瓦特/文件依賴關係：靜態變量與AspNet緩存與memcached
在工作中，我們每天獲得大約200,000頁面瀏覽量。在我們的主頁上，我們展示了一個促銷。對於不同的用戶，根據其原籍國和語言的不同，此促銷活動也會有所不同。
所有不同的促銷都在每個Web服務器上的XML文件中定義。我們有12臺Web服務器都使用相同的XML文件爲同一站點提供服務。根據國家/語言，大約有50種不同的促銷組合。我們想象我們永遠不會有超過200個（如果有的話）促銷（組合）總數。
XML文件可能隨時更改，超出發佈週期。當它發生變化時，新的促銷定義應立即在活動網站上更改。爲此需求實現功能是另一位開發人員和我的責任。
最初，我編寫了代碼，以便解析XML文件的內容，然後將其存儲在類的靜態成員中。 A FileSystemWatcher監視對文件的更改，並且每當文件發生更改時，XML將被重新加載/重新分配，並且靜態成員將使用新內容更新。看起來像一個堅實而簡單的解決方案，可以通過XML文件保存當前促銷活動的內存字典。 （每個服務器都會獨立執行其XML文件的本地副本;所有XML文件都是相同的，並且同時發生更改。）
我正在工作的其他開發人員擁有高級職位，並且認定這不是好。相反，我們應該將每個服務器的HttpContext.Current.Cache中的所有促銷與CacheDependency文件相關性一起存儲，該文件相關性會自動監控文件更改，並在文件更改時清除緩存的促銷活動。雖然我喜歡這一點，但我們不再需要使用FileSystemWatcher，但我擔心一點，即從volitile緩存而不是靜態類成員獲取促銷的性能會降低。
後來（護理對這個問題有何評論？我已經放棄了主張不切換到HttpRuntime.Cache。），之後我們開始使用HttpRuntime.Cache，我們通過與Enyim memcached的作爲我們的.NET接口其他業務問題（例如搜索結果）。當我們這樣做時，這位Sr. Developer決定我們應該使用memcached而不是HttpRuntime（HttpContext）Cache來存儲促銷信息。高層稱「是的，聽起來不錯」，並且爲他推出了一個專門爲memcached服務的服務器。現在他正在實施更改以使用memcached。
我很懷疑這是一個很好的決定。我們現在打開一個到網絡memcached服務器的套接字並將其價值傳輸到我們的Web服務器，而不是繼續處理並從HttpRuntime.Cache中獲取此促銷數據。
這必須是不夠高性能的，對不對？即使緩存是memcached。 （我還沒有機會編譯任何性能指標呢。）
最重要的是，他將不得不通過memcached設計自己的文件依賴性解決方案，因爲它不提供這樣的功能。
我最初的設計不是最好的嗎？這是否會導致你過度工程？是否需要HttpRuntime.Cache緩存或memcached緩存？