我們的客戶每個應用程序服務器有數百個項目。每個項目都有自己的元數據描述符（內存大約1MB，從DB加載大約1sec）。 元數據用於在各個方面驗證對服務器的每個請求（權限，有效字段，字段值等）。我們嚴重依賴於此元數據。如何調整應用程序服務器中的緩存
爲了節省查詢數據庫的時間，我們決定實施緩存機制（使用EHCache）來存儲項目的元數據。我們希望適當調整緩存。
我想知道，什麼是調整高速緩存的性能（總規模，對象數量，疏散策略...）
例如技術，應該還沒有被一段訪問的對象時間被釋放以節省內存？如何選擇驅逐戰略（如LRU，MRU）？
我們確實有一個經驗豐富的負載測試團隊和大量來自客戶的數據（項目數量，平均元數據大小等等），所以構建負載測試環境應該不成問題。我只是不確定我應該尋找什麼？
請分享您的緩存調整經驗。
謝謝
關於緩存的關鍵統計數據非常簡單......緩存缺失率。你想要統計某人問緩存什麼的次數，以及「某事」不在緩存中的次數，後者除以前者是你的失敗率。
就是這樣。找到一個可靠的方法來衡量你的應用程序，其他的只是簡單地運行測試。每次調整，在現實環境下進行負載測試以檢查錯過率的變化。可用的參數太依賴於問題的細節。
我通常會從LRU開始，增加大小，直到我看到未命中率的收益遞減，然後嘗試使用相同大小的LFU來查看它的比較。當然，除非你碰巧知道你的病例對LRU是病態的。
最佳驅逐策略可能取決於具體數據以及它如何使用。
這裏有幾個通用的例子：
新聞內容 - 文章每天都在增加，並幾乎從不修改 - 緩存用於減輕數據庫服務器上的需求。驅逐戰略應該圍繞許多閱讀量身定做，但幾乎不寫。
論壇主題（可能不是最好的例子） - 驅逐策略應該圍繞許多讀取而定製，但也圍繞着頻繁的寫入。雖然新聞內容可以使用最近最少使用（LRU）逐出策略最優化地配置，但是本示例中的論壇線程可以使用最少使用（LFU）逐出策略來更優化地配置。當添加新消息時，論壇線程的緩存無論如何都需要經常替換，但是，LFU策略會將最活躍的線程保留在緩存中。