在ASP.NET Web API中使用MD5實現HTTP緩存Etag功能

我正在閱讀有關HTTP緩存的Google性能文檔，文檔號爲https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching，本文檔指出我們應儘可能使用ETags。我正在使用ASP.NET Web Api 2.2。我現在正試圖在我所有的公共API中實現ETag。我正在考慮使用MD5來實現ETag。我的意思是，我將使用MD5對每個請求散列json響應。對每個請求使用MD5.calculateHash是否有任何性能問題？我的json響應大小不太大（在1到20KB的範圍內）。在ASP.NET Web API中使用MD5實現HTTP緩存Etag功能

來源

2014-10-28 user960567

是的，會有性能問題。計算哈希需要時間。但是，您可能會發現，計算該散列的成本與通過將不變的字節傳輸到客戶端所節省的性能相比並不顯着。

但是，我們不能保證您能夠通過Etags獲得性能改善。這取決於很多事情。您是否要在每次請求時重新生成服務器上的Etag，以將其與傳入請求進行比較？或者你打算創建一個etag值的緩存，並在資源更改時使它們失效？

如果您要在每個請求中重新生成etag，那麼從數據庫中提取數據並格式化表示的時間可能會大大超過在線路上發送幾個字節所花費的時間。特別是如果整個表示可以適合單個網絡數據包。

這裏的關鍵在於詢問您是否真的需要Etags的性能增益，並且這是否值得執行。通過設置緩存控制頭來啓用客戶端專用緩存，可以爲您提供所需的所有優勢，而無需實施etags。

我有很多帖子說進入這個主題的詳細信息：

來源

2014-10-28 19:34:32

沒有數據庫交互。我只是在每個請求上使用MD5散列響應json，並將它與IfNoneMatch頭進行比較？做這個的最好方式是什麼？順便說一句，Google建議使用ETags – user960567 2014-10-28 19:55:02

@ user960567好吧，如果生成json響應的代價是零，那麼生成哈希的代價可能低於通過線路發送字節的代價，所以返回Etag可能會使得感。 – 2014-10-28 20:04:00

Darrel，坦率地說，我在所有公共API中使用Azure Redis Cache X分鐘。因此，我首先要做的是檢查redis緩存的響應，如果存在（或不存在從數據庫中獲取它），然後將其採用緩存控制max-age = X分鐘和ETag頭返回響應。在發送帶IfNoneMatch的響應檢查ETag之前。如果相同，則爲200，否則爲200.您如何看待這種方法？ – user960567 2014-10-28 20:14:37

在ASP.NET Web API中使用MD5實現HTTP緩存Etag功能

回答

相關問題