不，我第二個問題的答案不是冬天。前言：我最近對Entity Framework進行了很多研究，而令我困擾的是查詢未預熱時的性能，即所謂的冷查詢。我瀏覽了關于Entity Framework 5.0 的性能注意事項文章。作者介紹了“ 熱”和“ 冷”查詢的概念以及它們之間的區別，我也注意到自己而并不知道它們的存在。在這里可能值得一提的是，我只有六個月的經驗?，F在，我知道如果我想從性能方面更好地理解框架，我可以進一步研究哪些主題。不幸的是，Internet上的大多數信息已經過時或過分帶有主觀性，因此，我無法找到有關“ 熱與冷”查詢主題的任何其他信息。到目前為止，基本上我注意到的是，每當我需要重新編譯或回收命中時，我的初始查詢就會變得非常緩慢。如預期的那樣，任何后續數據讀取都是快速的（主觀的）。我們將遷移到Windows Server 2012，IIS8和SQL Server 2012，作為一名初級學生，我實際上贏得了自己在其余測試之前進行測試的機會。我很高興他們引入了一個預熱模塊，該模塊可以使我的應用程序為第一個請求做好準備。但是，我不確定如何繼續預熱我的實體框架。我已經知道值得做的事情：根據建議提前生成我的視圖。最終將模型移到單獨的裝配中。我認為，按照常識，可能做錯了什么：在應用程序啟動時讀取虛擬數據，以預熱，生成和驗證模型。問題：何時在我的實體框架上實現高可用性的最佳方法是什么？在什么情況下，實體框架會再次變得“冷”？（重新編譯，回收，IIS重新啟動等）
3 回答
滄海一幻覺
TA貢獻1824條經驗 獲得超5個贊
如果您希望在所有通話中獲得最佳性能，則應仔細考慮您的體系結構。例如，當應用程序加載時，將經常使用的查詢預先緩存在服務器RAM中可能是有意義的，而不是對每個請求都使用數據庫調用。該技術將確保對常用數據的最小應用程序響應時間。但是，您必須確保具有行為良好的到期策略，或者在進行任何會影響緩存數據的更改時始終清除緩存，以避免并發問題。
通常，您應該努力設計分布式體系結構，以便僅在本地緩存的信息過時或需要進行事務處理時才需要基于IO的數據請求。在內存緩存檢索中，任何“在線”數據請求的檢索時間通常比本地檢索時間長10-1000倍。僅憑這一事實，與“本地與遠程”數據問題相比，有關“冷數據與熱數據”的討論就顯得無關緊要了。
慕婉清6462132
TA貢獻1804條經驗 獲得超2個贊
一般提示。
執行嚴格的日志記錄，包括訪問內容和請求時間。
初始化應用程序以熱啟動從上一步中拾取的非常慢的請求時，請執行虛擬請求。
除非存在實際問題，否則不要費心進行優化，與應用程序的使用者進行交流并提出要求。如果只是想找出需要優化的內容，就可以輕松擁有一個連續的反饋循環。
現在來解釋為什么虛擬請求不是錯誤的方法。
降低復雜性 -您正在以一種可以在不更改框架的情況下運行的方式對應用程序進行預熱，并且無需弄清楚可能的時髦API /框架內部結構就可以正確地進行操作。
更大的覆蓋范圍 -您正在立即對與緩慢請求有關的所有緩存層進行預熱。
解釋高速緩存何時“冷”。
這種情況發生在您框架中應用緩存的任何層，性能頁頂部有一個很好的描述。
每當在可能使緩存失效的潛在更改之后必須驗證緩存時，這可能是超時或更智能的（即，緩存項的更改）。
逐出緩存項時，鏈接的性能文章中的“緩存逐出算法”部分對此進行了描述，但總而言之。
LFRU（最不常用-最近使用）緩存命中次數和年齡，限制為800個項目。
您提到的其他內容（特別是重新編譯和重新啟動IIS）會清除部分或全部內存緩存。
- 3 回答
- 0 關注
- 532 瀏覽
添加回答
舉報
0/150
提交
取消