Entity Tags (ETags) are commonly used in Web applications to effectively leverage the power of using web farms, which is a non-fancy term for HTTP/S load balancing. In web farms, a common practice is to set what is called ETags as it helps enhance performance in web farm scenarios. ETags is controlled in IIS by a metabase property (ETAG_CHANGENUMBER) and this value is sent back to clients via response headers as instructed by the HTTP RFC 2616.
If the ETag value is the same across a number of servers, then clients are not required to re-download content that already exists in the clients cache. Without this value set to the same, clients might communicate on subsequent requests to another server in the web farm and receive an unnecessary response of data from the IIS server.
For purposes of this blog, I will focus on modifications rather than further definition of ETags. However, you can read more in the IIS 6.0 documentation on ETags to get more familiar with them.
...Web Farms, IIS 6.0 & RTM
A change that has caused a few of our customers issues when upgrading to Windows Server 2003 & IIS 6.0 is a change to our ETag computation. At RTM, we changed our behavior from IIS 5.0 hence causing IIS customers large problems as increase in traffic began to occur once migrating to IIS 6.0. The cause of this issue was a known bug, 823544, and was fixed prior to the release of Service Pack 1. Beyond that, we found an additional bug, 900245, that caused the ETag value to change when the IIS 6.0 metabase configuration was changed. This would be an expensive change in web farms because this would cause sync scripts to be sure to validate this new ETag value across all servers during their deployment.
As with any major update, it is in the best interest for customer's to avoid these bugs by installing Service Pack 1 which integrates these two fixes for delivery in a major milestone.
...Web Farms, IIS 6.0 & Service Pack 1 (slipstream)
In slipstream installs, you do not need to do anything other than set the ETag value to match across your web farm servers. The problems with ETag mentioned above have been fixed and should work as designed.
...IIS 6.0 & IIS 7.0 - Making it work
In comes IIS7, the next generation platform for web applications for Microsoft. The headaches caused by these changes in IIS 6.0 were heard loud and clear as we have changed this behavior. In IIS7, the ETAG_CHANGENUMBER value is now set to "0" as to not interfere with deployments to web farms.
The key take away is that as IIS7 servers start to integrate into your environment with other IIS 6.0 servers is that you will need to change the ETAG value property to "0" to match the IIS7 servers. If you do not, then you will see performance go down as client's caches are invalidated.
To do so, do the following:
- Locate adsutil.vbs (typically in %systemroot%\inetpub\adminscripts)
- In that directory, issue the following command:
cscript adsutil.vbs set w3svc/etag_changenumber 0
I bring this up as it recently came up internally as we have some internal deployments that had this value set in the metabase on their IIS 6.0 installations. Upon deploying IIS7, they came upon this problem and had to modify the behavior as they integrated IIS7 & IIS 6.0 servers together in their web farms.
As mentioned above, if you dedicate your IIS7 servers to their own web farm as to avoid this problem. I hope this might help some of you avoid this issue in your future deployments.