HEAD request performance

Question

We are currently testing performances on our web servers and are getting very different results between production servers and test servers.

The test we are making is the following:

• Download the RSS feed XML available on the site
• Make a HEAD request of all links present on into the XML feed to check if url is correct

Suprisingly the average response time on the Test servers is around 15ms when the same measurement reads 900 ms on prod servers. As both servers are (supposed to be) configured identically, I am very puzzled by those results.

1. Am I correct in thinking that HEAD requests of .CFM pages do not actually involve the ColdFusion server but only IIS?
2. If I am correct with the first point, where can I check on the IIS level what can make such a difference in response time?

Following up on the suggestions I received from you guys, I simply tried to add a log entry into a test cfm page to see if the CFLog gets executed or not.

Surprisingly, the same HEAD request on the same file generates a log entry in prod. and not in test. Obviously, the config should be different between test and prod but I don't know at which level.

Answer 1

Your first assumption is incorrect. A response to a HEAD request has to be coded and isn't handled automatically. A HEAD request should respond with identical header information as a GET request, which generally means executing the same code as a GET request and then omitting the message-body in the response.

From the HTTP spec, section 9.4:

The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.

The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.

I think it's very rare to see dynamic sites, CMSs or frameworks that actually implement the majority of things like HEAD responses, valid ETags, etc - so generally you'll get identical responses from a GET and a HEAD, including the message-body that is supposed to be stripped from a HEAD request.

I'm assuming that what you're experiencing in the time difference is attributable to content differences between the servers. That is, a test server may only have minimal content and therefore executes faster than the full content production servers.