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

问题描述

设置一个REST Web服务只需要尽可能快地回答YES或NO。设计一个HEAD服务似乎是最好的方法这样做，但我想知道如果我真的会获得一些时间，而不是做一个GET请求。

我想我的身体流不会在我的服务器上打开/关闭（约1毫秒？）。
由于要返回的字节数量非常少，因此在IP数据包号码中，我是否可以在传输中获得任何时间？

感谢您的回应！

编辑：

为了进一步解释上下文：

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

由于最后一个服务会被非常大的一组客户端调用（每5ms期望一个调用），所以我想知道使用HEAD方法是否可以进行有价值的优化？约250个字符在响应主体中返回。 HEAD方法至少可以获得这些250个字符的传输，但这会带来什么影响？我试图用两个方法（HEAD和GET）之间的差别来衡量， 1000次调用，但根本看不到增益（< 1ms）...

解决方案

RESTful URI应代表服务器上的资源。资源通常作为记录存储在数据库或文件系统上的文件中。除非资源很大或者在服务器上检索速度慢，否则使用 HEAD 而不是 GET 可能无法获得可衡量的收益$ C>。这可能是因为检索元数据的速度并不比检索整个资源快。

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

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

例如，假设您想检查资源123是否存在。 200 表示是，而 404 表示否：

  HEAD / resources / 123 HTTP / 1.1 
 [...] 
 
 HTTP / 1.1 404未找到
 [ ...] 
  

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

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

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.

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?

Thanks in advance for your response!

Edit:

To explain further the context:

• I have a set of REST services executing some processes, if they are in an active state.
• I have another REST service indicating the state of all these first services.

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?

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)...

解决方案

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.

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.

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.

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
[...]

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 vs GET性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！