upstream timed out (110: Connection timed out) while reading response header from upstream

tianxiaoyongcs · 2019-07-25T20:51:16+00:00

抓包中显示，在建立TLS连接的过程中，只到 Server He...

upstream timed out (110: Connection timed out) while reading response header from upstream

tianxiaoyongcs

我正在使用openresty 1.15.8.1（感谢春哥）, 写了一个比较简单的网关，但是今天在压测的时候出现了一个问题。问题如下：

也就是在反向代理的时候，每当60s出现了一次。

当配置了 proxy_read_timeout 之后，会随着配置的这个时间而出现以上问题。我在想如果将这个proxy_read_timeout 的时间设置的足够大的话，应该会降低出现上面错误的概率，但是我担心会对性能有影响，不知道各位大佬有什么好的解决方案吗？

测试配置如下：

tel: 18336032131

email：tianxi...@gmail.com

address: 上海

Sender notified by
Mailtrack 19/07/25 下午8:49:59

doujiang24

这个问题是你的上游响应太慢了，肯定不能通过改 proxy_read_timeout 来解决问题，这个只是掩盖问题

你需要排查一下，是不是你的上游被你压测顶不住了，还是中间调用有啥错误

最方便的办法还是抓包分析一下

6 Mr.Tian172 <tianxi...@gmail.com> 于2019年7月25日周四下午8:51写道：

我正在使用openresty 1.15.8.1（感谢春哥）, 写了一个比较简单的网关，但是今天在压测的时候出现了一个问题。问题如下：

也就是在反向代理的时候，每当60s出现了一次。

当配置了 proxy_read_timeout 之后，会随着配置的这个时间而出现以上问题。我在想如果将这个proxy_read_timeout 的时间设置的足够大的话，应该会降低出现上面错误的概率，但是我担心会对性能有影响，不知道各位大佬有什么好的解决方案吗？

测试配置如下：

--
tel: 18336032131
email：tianxi...@gmail.com
address: 上海

Sender notified by
Mailtrack 19/07/25 下午8:49:59

tianxiaoyongcs

德江你好：

我发现在跑业务的时候会出现大量的tcp的TIME_WAIT，短短几秒钟就达到了峰值；我也试一下贵司开发的APISIX,发现并没有这个问题，我想问下是不是APISIX做了什么处理？

当我用openresty只是去跑一个proxy_pass的时候也会出现这个情况，我试过了修改服务器的内核参数去降低TIME_WAIT，但是会引发服务器的网络波动，

导致请求卡顿的情况，所以就想请教一下有没有好的方案去优化这个问题呢？

apisix:

自己开发的网关：

纯openresty:

Sender notified by
Mailtrack 19/07/28 下午2:41:48

DeJiang Zhu <douj...@gmail.com> 于2019年7月27日周六上午9:21写道：

这个问题是你的上游响应太慢了，肯定不能通过改 proxy_read_timeout 来解决问题，这个只是掩盖问题

你需要排查一下，是不是你的上游被你压测顶不住了，还是中间调用有啥错误
最方便的办法还是抓包分析一下

6 Mr.Tian172 <tianxi...@gmail.com> 于2019年7月25日周四下午8:51写道：
我正在使用openresty 1.15.8.1（感谢春哥）, 写了一个比较简单的网关，但是今天在压测的时候出现了一个问题。问题如下：

也就是在反向代理的时候，每当60s出现了一次。

当配置了 proxy_read_timeout 之后，会随着配置的这个时间而出现以上问题。我在想如果将这个proxy_read_timeout 的时间设置的足够大的话，应该会降低出现上面错误的概率，但是我担心会对性能有影响，不知道各位大佬有什么好的解决方案吗？

测试配置如下：

--
tel: 18336032131
email：tianxi...@gmail.com
address: 上海

Sender notified by
Mailtrack 19/07/25 下午8:49:59

address: 上海

doujiang24

你这种很有可能就是没有开启 keepalive，使用短连接就很容易出现这个问题

ps: APISIX 并不是 OpenResty Inc. 的产品，只是 openresty 社区中的产品

6 Mr.Tian172 <tianxi...@gmail.com> 于2019年7月28日周日下午2:42写道：

德江你好：
我发现在跑业务的时候会出现大量的tcp的TIME_WAIT，短短几秒钟就达到了峰值；我也试一下贵司开发的APISIX,发现并没有这个问题，我想问下是不是APISIX做了什么处理？
当我用openresty只是去跑一个proxy_pass的时候也会出现这个情况，我试过了修改服务器的内核参数去降低TIME_WAIT，但是会引发服务器的网络波动，
导致请求卡顿的情况，所以就想请教一下有没有好的方案去优化这个问题呢？

apisix:

自己开发的网关：

纯openresty:

Sender notified by
Mailtrack 19/07/28 下午2:41:48

DeJiang Zhu <douj...@gmail.com> 于2019年7月27日周六上午9:21写道：
这个问题是你的上游响应太慢了，肯定不能通过改 proxy_read_timeout 来解决问题，这个只是掩盖问题

你需要排查一下，是不是你的上游被你压测顶不住了，还是中间调用有啥错误
最方便的办法还是抓包分析一下

6 Mr.Tian172 <tianxi...@gmail.com> 于2019年7月25日周四下午8:51写道：
我正在使用openresty 1.15.8.1（感谢春哥）, 写了一个比较简单的网关，但是今天在压测的时候出现了一个问题。问题如下：

也就是在反向代理的时候，每当60s出现了一次。

当配置了 proxy_read_timeout 之后，会随着配置的这个时间而出现以上问题。我在想如果将这个proxy_read_timeout 的时间设置的足够大的话，应该会降低出现上面错误的概率，但是我担心会对性能有影响，不知道各位大佬有什么好的解决方案吗？

测试配置如下：

--
tel: 18336032131
email：tianxi...@gmail.com
address: 上海

Sender notified by
Mailtrack 19/07/25 下午8:49:59

tianxiaoyongcs

德江你好：

你说的没错，确实是这个样子；我现在走了一层upstream之后明显TIME_WAIT的数量降低了，并且time out 的情况也不会发生了。

Sender notified by
Mailtrack 19/07/29 上午8:55:50

DeJiang Zhu <douj...@gmail.com> 于2019年7月29日周一上午8:35写道：

你这种很有可能就是没有开启 keepalive，使用短连接就很容易出现这个问题

ps: APISIX 并不是 OpenResty Inc. 的产品，只是 openresty 社区中的产品

6 Mr.Tian172 <tianxi...@gmail.com> 于2019年7月28日周日下午2:42写道：

德江你好：
我发现在跑业务的时候会出现大量的tcp的TIME_WAIT，短短几秒钟就达到了峰值；我也试一下贵司开发的APISIX,发现并没有这个问题，我想问下是不是APISIX做了什么处理？
当我用openresty只是去跑一个proxy_pass的时候也会出现这个情况，我试过了修改服务器的内核参数去降低TIME_WAIT，但是会引发服务器的网络波动，
导致请求卡顿的情况，所以就想请教一下有没有好的方案去优化这个问题呢？

apisix:

自己开发的网关：

纯openresty:

Sender notified by
Mailtrack 19/07/28 下午2:41:48

DeJiang Zhu <douj...@gmail.com> 于2019年7月27日周六上午9:21写道：
这个问题是你的上游响应太慢了，肯定不能通过改 proxy_read_timeout 来解决问题，这个只是掩盖问题

你需要排查一下，是不是你的上游被你压测顶不住了，还是中间调用有啥错误
最方便的办法还是抓包分析一下

6 Mr.Tian172 <tianxi...@gmail.com> 于2019年7月25日周四下午8:51写道：
我正在使用openresty 1.15.8.1（感谢春哥）, 写了一个比较简单的网关，但是今天在压测的时候出现了一个问题。问题如下：

也就是在反向代理的时候，每当60s出现了一次。

当配置了 proxy_read_timeout 之后，会随着配置的这个时间而出现以上问题。我在想如果将这个proxy_read_timeout 的时间设置的足够大的话，应该会降低出现上面错误的概率，但是我担心会对性能有影响，不知道各位大佬有什么好的解决方案吗？

测试配置如下：

--
tel: 18336032131
email：tianxi...@gmail.com
address: 上海

Sender notified by
Mailtrack 19/07/25 下午8:49:59

address: 上海