以编程方式发出请求时要使用的合理 HTTP POST 超时值？
当以编程方式发出 HTTP POST 请求时，什么超时值比较合理？
就我而言，我希望在 PHP 中发出 POST 请求时设置“合理”的超时值，但这适用于任何语言。
我需要能够发出一组请求，每个请求都发送到用户指定的 URL。 如果我确实需要连续而不是同时处理请求，我想指定一个合理的时间，超过该时间请求将被视为超时。
PHP 的 默认套接字超时是 60 秒。 在决定请求不会完成之前，这似乎是不必要的长时间等待。
由于这些是 POST 请求，它们应该快速完成 - 不像 GET 请求那样需要检索和返回数据。
我们应该能够假设，大多数时候，未能在 X 秒内对请求发出响应意味着主机不太可能在合理的时间内针对 X < 的值发出响应em>显着小于 60。
当然，主机响应简单的 POST 请求的时间很少会超过 60 秒。 他们的时间很少超过 10 秒吗？ 5秒？
在实践中 X 的合理值是什么？ 伴随建议的理由将非常有益。
When programmatically issuing HTTP POST requests, what timeout values would be sensible?
In my case, I'm looking to set 'sensible' timeout values when making POST requests in PHP, however this applies to any language.
I need to be able to issue a set of requests, each to a user-specified URL. If I do need to process requests consecutively instead of concurrently, I'd like to specify a sensible time beyond which a request is deemed to have timed out.
PHP's default socket timeout is 60 seconds. This seems an unnecessarily long time to wait before deciding a request is not going to be completed.
As these are POST requests they should complete quickly - there's no data to be retrieved and returned as with a GET request.
We should be able to assume, most of the time, that the failure to issue a response to a request within X seconds means the host is unlikely to issue a response within a reasonable time for values of X significantly less than 60.
Surely hosts rarely take more than 60 seconds to respond to a simple POST request. Do they even rarely take more than 10 seconds? 5 seconds?
What might be sensible values for X in practice? Justifications accompanying suggestions would be extremely beneficial.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议进行一次测试，因为涉及的因素太多，无法给出始终合理的值。
POST 请求发送要处理的数据。 处理需要多长时间？ 这将是特定于应用程序/数据的。
楼主在哪里？ 用户正在提供 URL，因此该 URL 是未知的。 我们无法知道您的应用程序和主机之间的流量如何。 我们无法知道主机的服务器负载。
本质上，不存在通用的合理超时。 您必须根据您的具体需求做出最佳判断。 设置一个测试并用它来确定你的极限。
I would recommend setting up a test, as there are too many factors involved to give a value that will always be sensible.
A POST request sends data to be processed. How long with the processing take? This will be application/data specific.
Where is the host? The user is supplying the URL, so that will be unknown. We can't know what traffic is like between your application and the host. We can't know the server load of the host.
Essentially, there is no universal sensible timeout. You have to use your own best judgment based on your specific needs. Set up a test and use that to determine your limits.
大多数库都有连接超时和读取超时。 也就是说，尝试连接到远程服务器之间的超时，以及发送请求后等待响应的超时。
如果这是本地 Web 服务，我会将连接超时设置为低 1 秒，或者如果您的库支持的话更短。 如果您要连接的远程服务不可用，恕我直言，最好立即向用户返回响应，而不是允许所有工作线程阻塞该远程服务，从而导致其他上游错误。
至于读取超时，这是比较棘手的，您需要它较低，这样您就不会耗尽等待远程服务返回的工作人员池，但您也不希望它太低以至于关闭读取响应之前的连接。 这是您必须测试的内容，然后在系统投入生产时作为指标进行跟踪。
Most libraries have a connect timeout and a read timeout. That is, the timeout between trying to connect to the remote server, and the timeout after sending the request, that they should wait for a response.
If this is a local web service, I would set the connect timeout low, 1 second, or less if your library supports it. If the remote service you are connecting to is unavailable IMHO its better to return a response to the user immediately, than to allow all your worker threads to block on that remote service, causing other upstream errors.
As for the read timeout, that is trickier, you need it to be low, so you don't exhaust your pool of workers who are waiting for the remote service to return, but you also don't want it so low that it closes the connection before reading a response. That is something you'll have to test, then track as a metric when your system is in production.