记一次go httpclient [读取响应Body超时]的排查过程。
今年度解锁的第一个技能。
1故障现场
本人负责的主备集群,发出的 HttpClient 请求有 30%概率超时， 报context deadline exceeded (Client.Timeout or context cancellation while reading body) 异常
Kibana 显示 Nginx 处理请求的耗时request_time在[5s-1min]区间波动， upstream_response_time在 2s 级别。
所以我们认定是 Nginx 向客户端回传 50M 的数据，发生了网络延迟。于是将 HttpClient Timeout 从 30s 调整到 60s， 上线之后明显改善。
But 昨天又出现了一次同样的超时异常
- time="2022-01-05T22:28:59+08:00" ....
- time="2022-01-05T22:30:02+08:00" level=error msg="service Run error" error="region: sz,first load self allIns error:context deadline exceeded (Client.Timeout or context cancellation while reading body)"
2线下复盘
go的HttpClient Timeout包括连接、重定向(如果有)、从Response Body读取的时间，内置定时器会在Get，Head、Post、Do 方法之后继续运行，直到读取完Response.Body.
Timeout specifies a time limit for requests made by this Client. The timeout includes connection time, any redirects, and reading the response body. The timer remains running after Get, Head, Post, or Do return and will interrupt reading of the Response.Body.
Kibana 显示 Nginx 处理请求的耗时request_time才 32s, 远不到我们对于 Http 客户端设置的 60s 超时阈值。
这里有必要穿插 Nginx Access Log 的几个背景点
1.Nginx 写日志的时间 根据nginx access log[1]官方，NGINX writes information about client requests in the access log right after the request is processed. 也就是说 Nginx 是在端到端请求被处理完之后才写入日志。
2.Nginx Request_Time upstream_response_time
- $upstream_response_time – The time between establishing a connection and receiving the last byte of the response body from the upstream server
从 Nginx 向后端建立连接开始到接受完数据然后关闭连接为止的时间
- $request_time– The total time spent processing a request
Nginx 从接受用户请求的第一个字节到发送完响应数据的时间
从目前的信息看，Nginx 从接受请求到发送完响应流，总共耗时 32s。那剩下的 28s，是在哪里消耗的?
3三省吾身
这是我抽离的 HttpClient 的实践， 常规的不能再常规。
- package main
- import (
- "bytes"
- "encoding/json"
- "io/ioutil"
- "log"
- "net/http"
- "time"
- )
- func main() {
- c := &http.Client{Timeout: 10 * time.Second}
- body := sendRequest(c, http.MethodPost)
- log.Println("response body length:", len(body))
- }
- func sendRequest(client *http.Client, method string) []byte {
- endpoint := "http://mdb.qa.17usoft.com/table/instance?method=batch_query"
- expr := "idc in (logicidc_hd1,logicidc_hd2,officeidc_hd1)"
- jsonData, err := json.Marshal([]string{expr})
- response, err := client.Post(endpoint, "application/json", bytes.NewBuffer(jsonData))
- if err != nil {
- log.Fatalf("Error sending request to api endpoint, %+v", err)
- }
- defer response.Body.Close()
- body, err := ioutil.ReadAll(response.Body)
- if err != nil {
- log.Fatalf("Couldn't parse response body, %+v", err)
- }
- return body
- }
核心就两个动作
- 调用Get、Post、Do方法发起 Http 请求， 如果无报错，则表示服务端已经处理了请求
- iotil.ReadAll表示客户端准备从网卡读取 Response Body (流式数据), 超时异常正是从这里爆出来的
报错内容："Client.Timeout or context cancellation while reading body" 读取 Response Body 超时，
潜台词是：服务器已经处理了请求，并且开始向客户端网卡写入数据。
根据我有限的网络原理/计算机原理，与此同时，客户端会异步从网卡读取 Response Body。
写入和读取互不干扰，但是时空有重叠。
所以[读取 Body 超时]位于图中的红框区域，这就有点意思了。
- 之前我们有 30%概率[读取 Body 超时]，确实是因为 Nginx 回传 50M 数据超时，这在 Nginx request_time 上能体现。
- 本次 Nginx 显示 request_time=32s, 却再次超时，推断 Nginx 已经写完数据，而客户端还没有读取完 Body。
至于为什么没读取完，这就得吐槽iotil.ReadAll的性能了。客户端使用 iotil.ReadAll 读取大的响应体，会不断申请内存(源码显示会从 512B->50M)，耗时较长，性能较差、并且有内存泄漏的风险。客户端机器稍有差池，可能就会导致读大Body超时， 下一篇我会讲解针对大的响应体替换iotil.ReadAll的方案[2]。
为了模拟这个偶发的情况，我们可在Post、iotil.ReadAll前后加入时间日志。
- $ go run main.go
- 2022/01/07 20:21:46 开始请求: 2022-01-07 20:21:46.010
- 2022/01/07 20:21:47 服务端处理结束: 2022-01-07 20:21:47.010
- 2022/01/07 20:21:52 客户端读取结束: 2022-01-07 20:21:52.010
- 2022/01/07 20:21:52 response body length: 50575756
可以看出，当读取大的响应体时候，客户端iotil.ReadAll的耗时并不算小，这块需要开发人员重视。
我们甚至可以iotil.ReadAll之前time.Sleep(xxx)， 就能轻松模拟出生产环境的读取 Body 超时。
4我的收获
1.Nginx Access Log 的时间含义
2.go 的 HttpClient Timeout 包含了连接、请求、读取 Body 的耗时
3.通过对[读取 Body 超时异常]的分析，我梳理了端到端的请求耗时、客户端的行为耗时的时空关系， 这个至关重要。
引用链接
[1] nginx access log: https://docs.nginx.com/nginx/admin-guide/monitoring/logging/
[2] 替换iotil.ReadAll的方案: https://stackoverflow.com/questions/52539695/alternative-to-ioutil-readall-in-go
