Performance of HEAD requests
We are currently testing performances on our web servers and getting very different results between production servers and test servers.
The test we are doing is as follows:
- Download the XML RSS feed on the site
- Make a HEAD request for all links present in the XML feed to validate the URL.
Confidently average response time on test servers is around 15ms when the same measurement reads 900ms on prod servers. Since both servers are (presumably) configured the same, I am very puzzled by these results.
- Am I correct in assuming that HEAD requests on .CFM pages are not actually related to the ColdFusion server, but only to IIS?
- If I am right with the first point where can I check the IIS level, what can affect the response time?
Following the advice I got from you, I just tried to add a log entry to the cfm test page to see if CFLog is running or not.
Surprisingly, the same HEAD request on the same file generates a log entry in prod. and not in the test. Obviously the config should be different between test and prod, but I don't know at what level.
source to share
Your first guess is wrong. The response to the request HEAD
must be encoded and not automatically processed. The request HEAD
must respond with identical header information as the request GET
, which usually means executing the same code as the request GET
and then omitting the message body in the response.
From the HTTP specification, section 9.4 :
The HEAD method is identical to GET, except that the server MUST NOT return a message body in response. The meta information contained in the HTTP headers in response to a HEAD request MUST be the same as the information sent in response to a GET request. This method can be used to retrieve meta information about an entity, implicit in the request without passing the entity body itself. This method is often used to check hypertext links for accuracy, availability, and recent changes.
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 object from this resource. If the values of the new field indicate that the cached object is different from the current object (as would be displayed by changing 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 most of the things like responses HEAD
, valid ETags , etc. - usually you will receive identical responses from GET
and HEAD
, including the body of the message, which should be removed from the request HEAD
.
I am guessing that what you are experiencing in the time difference is due to differences in content between the servers. That is, the test server can only have minimal content and therefore runs faster than full content creation servers.
source to share
I didn't know the answer to this question, but I knocked down the code to test it and got some results. Caveat: I am only using Tomcat internal web server and I am using CF10 (I note you are using CF8). I do not think that their disclaimers invalidate my findings in the context of your particular situation.
<!--- headMe.cfm --->
<cflog text="hit" file="headMe">
<!--- doHead.cfm --->
<cfhttp method="head" url="http://localhost/headMe.cfm" result="httpResponse" />
<cfdump var="#variables#">
So I'm looking at doHead.cfm, which executes the HTTP HEAD headMe.cfm. If headMe.cfm was actually executed, then we will get an entry in headMe.log. If not: no log entry.
The variable httpResponse
was legal and expected for a HEAD request and ... I got a log entry.
So my conclusion is that when a HEAD request is received, unfortunately, all CFML is actually being executed. I really don't think it should be. There is nothing in the HTTP spec that suggests that this should or should not cause "dynamic" requests to be fully executed, but it would be nice if it didn't, I think.
Anyway, HTH.
source to share