http HEAD 与 GET 性能 [英] http HEAD vs GET performance

问题描述

我正在设置一个 REST 网络服务，它只需要尽快回答是"或否".

I am setting-up a REST web service that just need to answer YES or NO, as fast as possible.

设计 HEAD 服务似乎是最好的方法，但我想知道与执行 GET 请求相比，我是否真的会获得一些时间.

Designing a HEAD service seems the best way to do it but I would like to know if I will really gain some time versus doing a GET request.

我想我获得的正文流不会在我的服务器上打开/关闭(大约 1 毫秒?).由于要返回的字节数非常少，我是否会在传输中获得任何时间，IP 数据包数量?

I suppose I gain the body stream not to be open/closed on my server (about 1 millisecond?). Since the amount of bytes to return is very low, do I gain any time in transport, in IP packet number?

提前感谢您的回复！

进一步解释上下文:

• 我有一组 REST 服务正在执行某些进程(如果它们处于活动状态).
• 我有另一个 REST 服务，用于指示所有这些第一个服务的状态.

由于最后一个服务将被大量客户端频繁调用(预计每 5 毫秒调用一次)，我想知道使用 HEAD 方法是否是一种有价值的优化?响应正文中返回了大约 250 个字符.HEAD 方法至少获得了这 250 个字符的传输，但这有什么影响?

Since that last service will be called very often by a very large set of clients (one call expected every 5ms), I was wondering if using a HEAD method can be a valuable optimization? About 250 chars are returned in the response body. HEAD method at least gain the transport of these 250 chars, but what is that impact?

我尝试对两种方法(HEAD 与 GET)之间的差异进行基准测试，运行 1000 次调用，但根本看不到任何增益(<1ms)...

I tried to benchmark the difference between the two methods (HEAD vs GET), running 1000 times the calls, but see no gain at all (< 1ms)...

推荐答案

RESTful URI 应该代表服务器上的资源".资源通常存储为数据库中的记录或文件系统上的文件.除非资源很大或在服务器上检索速度很慢，否则使用 HEAD 而不是 GET 可能看不到可衡量的收益.可能是检索元数据并不比检索整个资源快.

A RESTful URI should represent a "resource" at the server. Resources are often stored as a record in a database or a file on the filesystem. Unless the resource is large or is slow to retrieve at the server, you might not see a measurable gain by using HEAD instead of GET. It could be that retrieving the meta data is not any faster than retrieving the entire resource.

您可以实现这两个选项并对它们进行基准测试以查看哪个更快，但我不会进行微优化，而是专注于设计理想的 REST 接口.从长远来看，干净的 REST API 通常比可能更快也可能不会更快的杂乱 API 更有价值.我并不反对使用 HEAD，只是建议您仅在正确"设计时使用它.

You could implement both options and benchmark them to see which is faster, but rather than micro-optimize, I would focus on designing the ideal REST interface. A clean REST API is usually more valuable in the long run than a kludgey API that may or may not be faster. I'm not discouraging the use of HEAD, just suggesting that you only use it if it's the "right" design.

如果您真正需要的信息是关于可以在 HTTP 标头中很好地表示的资源的元数据，或者要检查资源是否存在，HEAD 可能会很好地工作.

If the information you need really is meta data about a resource that can be represented nicely in the HTTP headers, or to check if the resource exists or not, HEAD might work nicely.

例如，假设您要检查资源 123 是否存在.200 表示是"，404 表示否":

For example, suppose you want to check if resource 123 exists. A 200 means "yes" and a 404 means "no":

HEAD /resources/123 HTTP/1.1
[...]

HTTP/1.1 404 Not Found
[...]

但是，如果您希望从 REST 服务中得到的是"或否"是资源本身的一部分，而不是元数据，则您应该使用 GET.

However, if the "yes" or "no" you want from your REST service is a part of the resource itself, rather than meta data, you should use GET.

这篇关于http HEAD 与 GET 性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！