search

buunguyen / combres

ASP.NET and MVC performance optimization library ⛺
Other
123 stars 37 forks source link

Version checking to control cache #14

Closed mikaelnet closed 10 years ago

mikaelnet commented 11 years ago

Hi,

In cluster setups with many content delivery servers, it’s usually impossible to deploy new versions of js/css files in an atomic operation. This means that a newly updated server will start serving links to resource sets with an updated version number, but the request for that resource may end up on another cluster node that hasn’t been updated yet. This means the client will get the old content with the new URL – and it’s being cached. Add a CDN to this, and the problem cannot be neglected. The fault will hit everyone.

One way of solving this could be to compare the incoming version number in RequestProcessor with the version number of the current resource set. If they differ, shorten the cache timeout to something like ten minutes (configurable), so that the content isn’t cached very long and will soon be refetched.

/ Mikael

buunguyen commented 11 years ago

That might work, must also prevent server from caching that response as well. Would you consider submit a PR?

mikaelnet commented 11 years ago

Sure! Actually, I looked into this and gave it a try. Though there were a few things that I didn't understand. For example, the server cache key is bound to the incoming version number. I'll get back to you on this when I have more details on this.

dplaskon commented 10 years ago

Another approach is to write your own IResourceSetCache implementation that uses a centralized cache (eg. couchbase, memcached, etc) so that all servers will be able to serve a request for either the "old" or "new" version of the resource from the centralized store.

buunguyen commented 10 years ago

@dplaskon that's a great idea!

buunguyen commented 10 years ago

Implement IResourceSetCache is the way to go. PR is welcome. Close this for now.