connection was closed问题指引

日志中出现类似错误比较常见，有些场景属于配置错误，有些场景属于性能问题，有些场景属于无法彻底解决的问题。这个 issue 主要帮助更好的定位和分析类似问题。

类似问题通过 label 做了标记： [查看](https://github.com/apache/servicecomb-java-chassis/issues?q=is%3Aissue+label%3Aconnection%26timeout+)

# 原理性介绍和定位技巧相关文章

[快速失败和重试](https://servicecomb.apache.org/references/java-chassis/zh_CN/references-handlers/fail-retry.html) : 介绍了随机故障发生的原理，以及在超时时间设置很短（需要快速失败的）的场景下的方案建议。
[性能问题分析和调优](https://servicecomb.apache.org/references/java-chassis/zh_CN/featured-topics/performance.html): 这类问题一般伴随性能问题发生。 介绍了如何分析性能问题，以及如何收集性能问题有关的日志。

# 关于 HTTP 连接
[TCP和HTTP连接的一些原理性介绍](https://blog.csdn.net/vikeyyyy/article/details/80760804)
微服务内部采用HTTP连接的情况下， 一般会复用连接，如果一个连接长时间不使用，则会回收。 常见的配置项有：

| 配置项 | 含义 |
| -- | -- |
|servicecomb.rest.client.connection.idleTimeoutInSeconds|客户端连接闲置时间。当客户端连接在规定的时间内，没有任何数据读入和写入，则会触发客户端主动关闭连接。[配置参考][client_config]|
|servicecomb.rest.client.connection.timeoutInMillis|连接建立的超时时间。如果在规定的时间内，没有成功建立连接，那么会关闭连接。[配置参考][client_config]|
|servicecomb.request.timeout|请求超时时间。客户端发出请求后，会等待服务端响应，如果在规定的时间内没有收到响应，那么客户端请求失败，并且会关闭连接。[配置参考][client_config]|
|servicecomb.rest.server.connection.idleTimeoutInSeconds|服务端连接闲置时间。当服务端连接在规定的时间内，没有任何数据读入和写入，则会触发服务端主动关闭连接。当服务端使用vert.x作为HTTP服务器的时候有效，如果使用其他web容器，比如Tomcat，相关配置请参考对应web容器的文档。[配置参考][server_config]|

建议 5<= servicecomb.request.timeout （毫秒 -> 秒） <= servicecomb.rest.client.connection.idleTimeoutInSeconds <= servicecomb.rest.server.connection.idleTimeoutInSeconds - 10 以避免随机故障和连接管理导致的随机失败概率。

# 关于随机故障

为了更好的理解随机故障，建议运行一下[最简单的性能测试用例](https://github.com/huaweicse/cse-java-chassis-benchmark)，并打开metrics观察各个环节的耗时情况。 这里只提供一些简单的结论和随机故障发生的原理描述。

* 在端到端平均时延为1ms左右的情况下，仍然有一些请求的最大时延超过700ms。***超时随机故障在高并发场景下，是必然会出现的一个故障，超时时间设置越短，发生故障的概率越高***。
* 时延抖动最厉害的环节有
* 获取连接(getConnect)：不可控因素包括网络故障、请求流量的突发性、大规模连接的管理。从metrics看出，平均获取连接时间小于1ms，但是最大可能等待100ms。
* 等待响应(waitResponse)：不可控因素包括服务端请求排队和派发的随机性；网络排队和传输的随机性。从Server和Client的metrics可以看出，Server的最大时延是100ms左右，而Client等待响应的最大时延有超过500ms的。
* 唤醒等待线程(wakeConsumer)：收到响应后，需要唤醒等待线程，等待线程进行后续处理。不可控因素主要体现为线程调度，CPU本身是被竞争的资源，CPU资源无法按照一个请求已经处理了多长时间进行分配。从metrics看出，平均唤醒等待线程时间小于1ms，但是最大可能等待200ms。
* 锁竞争：Client调用Server的handlersReq也有100ms左右的波动，这是因为启用了流控功能，流控功能存在锁。
* CPU竞争、内存竞争：对于一些纯CPU计算的逻辑，也存在时延波动，这些波动相对较小。比如Server端的执行逻辑，只是echo结果，平均时延可以忽略不计，最大时延也存在60ms的波动。这些波动的主要原因是CPU分时计算、垃圾回收等。可以看出，只要涉及到资源竞争：网络、线程池、连接池、CPU、锁等，就可能出现一个请求的处理被延迟。这个延迟的时间在平均时延小于1ms的情况下，可能高达500ms。 延迟的时间和并发请求数、TPS有很强的关联性。

***欢迎补充其他类似问题定位和处理经验***

[client_config]: https://servicecomb.apache.org/references/java-chassis/zh_CN/config-reference/rest-transport-client.html
[server_config]: https://servicecomb.apache.org/references/java-chassis/zh_CN/transports/rest-over-vertx.html

Commencez par examiner les indications existantes de l’issue, les références liées à la configuration du client et du serveur, ainsi que les issues connexes concernant les connexions et les timeouts. Une contribution finalisée rendrait explicites le périmètre du dépannage et les prochaines étapes, tout en préservant le contexte documenté des timeouts, des connexions, des performances et des métriques.

Rédigé par le modèle d'indexation à partir du texte de l'issue.