linux环境下http_client超时设置不生效的问题

[Archernarkiu]

在使用workflow的时候，关于http客户端超时，遇到了一个客户端超时设置不生效的问题，请问一下有什么排查思路

现场如下：

[Barenboim]

能不能看一下这个访问的域名是什么？有一种可能是DNS超时了，而我们内部没有把这个错误转换成DNS错误。我好像也遇到过这个问题。

@kedixa 关注一下DNS访问超时时候错误码的问题。我们目前应该是有一些情况没有正确修改为DNS error的。

[Barenboim]

@Archernarkiu 另外，你后面3个timeout，keep_alive_timeout，wait_timeout和watch_timeout都没有必要设置。

• keep_alive_timeout会根据http协议自动识别，如果你设置了就强制使用长连接。
• wait_timeout是同步等待超时时间，会在对单个ip连接数超过max_connections时进行同步等待。
• watch_timeout的意思是，允许watch_timeout时间内收到第一块返回数据再开始计算receive时间，主要用订阅类的需求。

[Barenboim]

从你截图的描述上看，感觉是dns超时了。目前我们 dns cache 默认的ttl是一个小时。你可以修改一下，是global settings里的dns_ttl_default这一项。访问dns是的超时控制，在global settings里的dns_server_params 。

你是什么域名，DNS请求了10秒没返回？

我这边通过一个不存在的DNS server，复现出DNS超时但返回system error了。@kedixa

[Barenboim]

综合看下来，应该是由于某个域名DNS cache过期之后，后端需要访问DNS。DNS的超时是10秒，这个域名大概5秒之后成功获得了IP信息。但IP连接不上，每次两秒超时。貌似你打开了两次重试，于是整体11秒后返回超时失败。

解决方法可以增加DNS cache有效期，减少DNS更新的频率。也可以减少http请求重试次数，避免产生多次连接超时。

[Archernarkiu]

能不能看一下这个访问的域名是什么？有一种可能是DNS超时了，而我们内部没有把这个错误转换成DNS错误。我好像也遇到过这个问题。

@kedixa 关注一下DNS访问超时时候错误码的问题。我们目前应该是有一些情况没有正确修改为DNS error的。

我们访问的域名是：https://api.bing.microsoft.com/v7.0/search?q=xxx

[Barenboim]

能不能看一下这个访问的域名是什么？有一种可能是DNS超时了，而我们内部没有把这个错误转换成DNS错误。我好像也遇到过这个问题。
@kedixa 关注一下DNS访问超时时候错误码的问题。我们目前应该是有一些情况没有正确修改为DNS error的。

我们访问的域名是：https://api.bing.microsoft.com/v7.0/search?q=xxx

你直接把dns_ttl_default加的到一天(配置为86400)吧。反正你是有重试的，如果连接失败，会根据dns_ttl_min这个参数更新DNS。

[Archernarkiu]

综合看下来，应该是由于某个域名DNS cache过期之后，后端需要访问DNS。DNS的超时是10秒，这个域名大概5秒之后成功获得了IP信息。但IP连接不上，每次两秒超时。貌似你打开了两次重试，于是整体11秒后返回超时失败。

解决方法可以增加DNS cache有效期，减少DNS更新的频率。也可以减少http请求重试次数，避免产生多次连接超时。

@Barenboim 非常感谢大佬提供的解答。

我对workflow的http网络任务理解如下，不知道是否正确。

1. create_http_task时，在请求ip、port的情况下，connect_timeout/send_timeout/receive_timeout 这三个设置实际上是通过框架内部的 epoll + timerfd 控制超时并做相应的处理的，所以会比较可靠
2. create_http_task时，在请求域名的情况下，需要先做dns解析出对应的ip，但是请求dns的过程并没有被框架可以配置的超时所控制，所以就会出现明明设置了connect_timeout/send_timeout/receive_timeout=2s，但是还会有一些请求耗时远过2s的情况

[Barenboim]

综合看下来，应该是由于某个域名DNS cache过期之后，后端需要访问DNS。DNS的超时是10秒，这个域名大概5秒之后成功获得了IP信息。但IP连接不上，每次两秒超时。貌似你打开了两次重试，于是整体11秒后返回超时失败。
解决方法可以增加DNS cache有效期，减少DNS更新的频率。也可以减少http请求重试次数，避免产生多次连接超时。

@Barenboim 非常感谢大佬提供的解答。

我对workflow的http网络任务理解如下，不知道是否正确。

1. create_http_task时，在请求ip、port的情况下，connect_timeout/send_timeout/receive_timeout 这三个设置实际上是通过框架内部的 epoll + timerfd 控制超时并做相应的处理的，所以会比较可靠
2. create_http_task时，在请求域名的情况下，需要先做dns解析出对应的ip，但是请求dns的过程并没有被框架可以配置的超时所控制，所以就会出现明明设置了connect_timeout/send_timeout/receive_timeout=2s，但是还会有一些请求耗时远过2s的情况

是啊，DNS server的超时在global settings里的dns_server_params。不过不建议改小DNS超时时间。另外，我感觉你好像设置了retry次数啊。如果设置了retry，那么请求就可能等待多次timeout时间。

[Archernarkiu]

访问 https://api.bing.microsoft.com/v7.0/search?q=xxx 的时候，我这边设置的 retry_max = 0， 没有重试过

[Barenboim]

访问 https://api.bing.microsoft.com/v7.0/search?q=xxx 的时候，我这边设置的 retry_max = 0， 没有重试过

全局还有一个ssl_connect_timeout你可以改一下，ssl的握手时间。这个默认也是10秒。