Guy kolbis

Guy,

You’re of course right that each server generates an unique e-tag for a file.  In fact, as the server uses some combination of time stamp and inode to generate the e-tag, different e-tags are returned for an identical file  if it is moved to a different location on disk even if it’s on the same server, or if the same file resides in multiple directories on one server.

There are a couple of other issues with using e-tags.  One is that objects served using  e-tags requires the browser to perform Conditional GET requests for the objects referenced in the page every time the browser loads the page. So although e-tags eliminate the need to download the tagged objects every time a page is visited,  the browser still must send a request to the server to validate the object and wait for the server to respond. Because  the greater the distance between the user and the data center means added latency for each request, doing Conditional GET requests for tagged objects does not reduce the page load time significantly. Another is that e-tagging takes up extra CPU and memory resources on the server for e-tag generation.

However, that doesn’t necessarily mean that a tag can’t be used in the manner you suggested with a load balancer. The F5 Local Traffic Manager (LTM) has an optional module called the WebAccelerator Module (WAM) that accelerates Web applications. When WAM is installed on LTM, it can check a file returned by a server and generate its own etag, called a pvtag.  The pvtag is similar to an e-tag in that it uniquely identifies content sent to the browser, but as it is generated by WAM, only one pvtag is generated per file regardless of its source. WAM generates the pvtag and re-writes the response to include the pvtag.

Doing so circumvents the problem you pointed out with using etags generated by a number of servers with a load balancer. More importantly however, the WebAccelerator module can serve versions of the objects that include cache-control headers with a long expiration time and thus effectively directs the browser to use the cached object for a longer period, eliminating the need for the browser to perform Conditional GET requests until the object expires.  WebAccelerator can do this while still ensuring that the browsers do not end up using stale content on subsequent visits if an object changes. The net effect of using pvtags and longer expiration is that pages load faster on repeat visits as the objects are re-loaded from browser cache without requiring Conditional GET requests.

Additionally, WAM can be deployed in both asymmetric and symmetric configurations.  When used in a symmetric configuration, customers that want to use e-tags without adding cache control headers can do so and still achieve better performance because once an object has been requested, it is stored in the remote WAM cache and served from that cache rather than the data center WAM cache, which reduces latency.  A side benefit in this case is that other users who request the same object also receive it from the remote WAM cache. Users that access the data center WAM asymmetrically still benefit by WAM dynamic caching.