coldfusion - HEAD请求性能

Question

我们目前正在我们的网络服务器上测试性能，并且在生产服务器和测试服务器之间得到非常不同的结果。

我们正在做的测试如下:

• 下载站点上可用的 RSS 提要 XML
• 对 XML 提要中存在的所有链接发出 HEAD 请求，以检查 url 是否正确

令人惊讶的是，测试服务器上的平均响应时间约为 15 毫秒，而生产服务器上的相同测量结果为 900 毫秒。由于两台服务器(应该)配置相同，我对这些结果感到非常困惑。

1. 我是否认为 .CFM 页面的 HEAD 请求实际上不涉及 ColdFusion 服务器而只涉及 IIS？
2. 如果我对第一点的看法是正确的，我在哪里可以检查 IIS 级别是什么导致响应时间如此不同？

按照我从你们那里收到的建议，我只是尝试将日志条目添加到测试 cfm 页面中以查看 CFLog 是否被执行。

令人惊讶的是，对同一个文件的同一个 HEAD 请求会在 prod 中生成一个日志条目。而不是在测试中。显然，测试和生产之间的配置应该不同，但我不知道在哪个级别。

Answer 1

您的第一个假设不正确。必须对 HEAD 请求的响应进行编码，并且不会自动处理。 HEAD 请求应使用与 GET 请求相同的 header 信息进行响应，这通常意味着执行与 GET 请求相同的代码，然后省略响应中的消息正文。

来自 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.

我认为很少看到动态站点、CMS 或框架实际实现了大部分内容，例如 HEAD 响应，有效 ETags , 等等 - 所以通常你会从 GET 和 HEAD 得到相同的响应，包括应该从 HEAD< 中剥离的消息正文 请求。

我假设您遇到的时差是由于服务器之间的内容差异造成的。也就是说，测试服务器可能只有最少的内容，因此比完整的内容生产服务器执行得更快。