Etag Generation and Server Side Caching

Nov 27, 2009 at 9:53 AM

Hi,

We think there might be an issue with combres caching of server side resources and etags generation. Our application has multiple web servers. Using the current date to generate the etag is causing a problem as the time on all web servers is not the same. The difference causes the etag to be generated differently, which results in the client re-requesting the resource, even though it has not changed. Also when the app pool recycles, this causes the server side cache to be invalidated, and the resources are reprocessed even though nothing has changed.

We suggest a solution to write the results to disk, using the resource set version and name to generate the file name. The etag generation would be based on the resource set version, and would be able to generate the same etag on multiple servers, and the servers would not have to reprocess the resource sets. Our build process updates the version number of the resource sets on each build. We would appreciate your thoughts on this proposed solution.

Thanks for a great product!

Regards,

Brian & Nick

Coordinator
Nov 29, 2009 at 5:30 AM

@Brian & Nick: thanks for posting the issue & suggestion. 

Your idea on the etag makes sense.  I'll address that in the next version.

I'm also considering implement a feature supporting different cache providers to be plugged into Combres (Velocity and DB comes to mind).  Even with that implemented, I need to spend more time thinking about cache invalidation  There are many things that cause a restart, plus many thing that may have occurred between the restart until the app is up again.  For example, the drop-in of a new filter or minifier DLL causes a restart, and unless the cache is invalidated, the new filter or minifier is not used until when the cache is expired or developers change the version of all resource sets which use that filter or minifier.  There's a tradeoff between application simplicity and the cache usage efficiency here (i.e. only invalidate the cache when its content is absolutely 100%-sure stale).  That said, the goal is move toward the latter without hurting much of the former (at least from Combres users' perspective).  I'll improve Combres along that line and hope each version of Combres will have better cache efficiency than the previous.

Nov 30, 2009 at 6:44 AM
Hi,

Thanks for the reply. I like your idea about pluggable cache providers, that makes alot of sense. For the moment, we are just sticking with the current caching mechanism, as for our needs at the moment, it seems ok. We have however changed the etag generation to the method mentioned about.

Kind Regards,
Brian

2009/11/29 buunguyen <notifications@codeplex.com>

From: buunguyen

@Brian & Nick: thanks for posting the issue & suggestion. 

Your idea on the etag makes sense.  I'll address that in the next version.

I'm also considering implement a feature supporting different cache providers to be plugged into Combres (Velocity and DB comes to mind).  Even with that implemented, I need to spend more time thinking about cache invalidation  There are many things that cause a restart, plus many thing that may have occurred between the restart until the app is up again.  For example, the drop-in of a new filter or minifier DLL causes a restart, and unless the cache is invalidated, the new filter or minifier is not used until when the cache is expired or developers change the version of all resource sets which use that filter or minifier.  There's a tradeoff between application simplicity and the cache usage efficiency here (i.e. only invalidate the cache when its content is absolutely 100%-sure stale).  That said, the goal is move toward the latter without hurting much of the former (at least from Combres users' perspective).  I'll improve Combres along that line and hope each version of Combres will have better cache efficiency than the previous.

Read the full discussion online.

To add a post to this discussion, reply to this email (combres@discussions.codeplex.com)

To start a new discussion for this project, email combres@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Coordinator
Dec 1, 2009 at 2:53 PM

I've changed the ETag generation algorithm.  Check out the latest code commit.

Dec 1, 2009 at 5:34 PM
Thanks you are a star

2009/12/1 buunguyen <notifications@codeplex.com>

From: buunguyen

I've changed the ETag generation algorithm.  Check out the latest code commit.

Read the full discussion online.

To add a post to this discussion, reply to this email (combres@discussions.codeplex.com)

To start a new discussion for this project, email combres@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com