I was reading Google performance document about HTTP caching at https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching, This document says that we should use ETags when possible. I am using ASP.NET Web Api 2.2. I am now trying to implement ETag in all of my public apis. I am thinking to implement ETag using MD5. I mean, I will hash the json response on each request using MD5. Is there any performance hit of using MD5.calculateHash on each request? My json response size are not too big(within the range of 1 to 20KB).
相关问题
- Angular RxJS mergeMap types
- Faster loop: foreach vs some (performance of jsper
- Google Apps Script: testing doPost() with cURL
- How to instantiate Http service in main.ts manuall
- Why wrapping a function into a lambda potentially
相关文章
- C#使用http访问网络,有办法用指定网卡访问网络嘛?
- Is a unicode user agent legal inside an HTTP heade
- DOM penalty of using html attributes
- Which is faster, pointer access or reference acces
- Django is sooo slow? errno 32 broken pipe? dcramer
- git: retry if http request failed
- Understanding the difference between Collection.is
- POSTing data to WebApi after update to 5.1.0 fails
Yes there will be a performance hit. Calculating a hash takes time. However, you may find that the cost of calculating that hash is not significant in comparison to the performance saved by transferring unchanged bytes over the wire to the client.
However, there is no guarantee that you will get a perf improvement with Etags. It depends on many things. Are you going to regenerate the Etag on the server on every request to compare it with the incoming request? Or are you going to create a cache of etag values and invalidate them when the resource changes?
If you are going to regenerate the etag on every request then it is possible that the time spent pulling data from the database and formatting the representation will be significantly higher than the time it takes to send a few bytes over the wire. Especially if the entire representation can fit in a single network packet.
The key here is to ask if you really need the performance gain of Etags and is it worth the cost of doing the implementation. Setting cache control headers to enable client side private caching may give you all the benefits that you need without having to implement etags.
I have a number of posts that go into this subject in more detail: