你好，我是孔令飞。
上一讲，我们学习了如何分析Go代码的性能。掌握了性能分析的基本知识之后，这一讲，我们再来看下如何分析API接口的性能。
在API上线之前，我们需要知道API的性能，以便知道API服务器所能承载的最大请求量、性能瓶颈，再根据业务对性能的要求，来对API进行性能调优或者扩缩容。通过这些，可以使API稳定地对外提供服务，并且让请求在合理的时间内返回。这一讲，我就介绍如何用wrk工具来测试API Server接口的性能，并给出分析方法和结果。
API性能测试，往大了说其实包括API框架的性能和指定API的性能。不过，因为指定API的性能跟该API具体的实现（比如有无数据库连接，有无复杂的逻辑处理等）有关，我认为脱离了具体实现来探讨单个API的性能是毫无意义的，所以这一讲只探讨API框架的性能。
用来衡量API性能的指标主要有3个：
这三个指标中，衡量API性能的最主要指标是QPS，但是在说明QPS时，需要指明是多少并发数下的QPS，否则毫无意义，因为不同并发数下的QPS是不同的。举个例子，单用户100 QPS和100用户100 QPS是两个不同的概念，前者说明API可以在一秒内串行执行100个请求，而后者说明在并发数为100的情况下，API可以在一秒内处理100个请求。当QPS相同时，并发数越大，说明API性能越好，并发处理能力越强。
在并发数设置过大时，API同时要处理很多请求，会频繁切换上下文，而真正用于处理请求的时间变少，反而使得QPS会降低。并发数设置过大时，请求响应时间也会变长。API会有一个合适的并发数，在该并发数下，API的QPS可以达到最大，但该并发数不一定是最佳并发数，还要参考该并发数下的平均请求响应时间。
此外，在有些API接口中，也会测试API接口的TPS（Transactions Per Second，每秒事务数）。一个事务是指客户端向服务器发送请求，然后服务器做出反应的过程。客户端在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
那么，TPS和QPS有什么区别呢？如果是对一个查询接口（单场景）压测，且这个接口内部不会再去请求其他接口，那么TPS=QPS，否则，TPS≠QPS。如果是对多个接口（混合场景）压测，假设N个接口都是查询接口，且这个接口内部不会再去请求其他接口，QPS=N*TPS。
Linux下有很多Web性能测试工具，常用的有Jmeter、AB、Webbench和wrk。每个工具都有自己的特点，IAM项目使用wrk来对API进行性能测试。wrk非常简单，安装方便，测试结果也相对专业，并且可以支持Lua脚本来创建更复杂的测试场景。下面，我来介绍下wrk的安装方法和使用方法。
wrk的安装很简单，一共可分为两步。
第一步，Clone wrk repo：
$ git clone https://github.com/wg/wrk
第二步，编译并安装：
$ cd wrk
$ make
$ sudo cp ./wrk /usr/bin
这里我们来看下wrk的使用方法。wrk使用起来不复杂，执行wrk --help可以看到wrk的所有运行参数：
$ wrk --help
Usage: wrk <options> <url>
Options:
-c, --connections <N> Connections to keep open
-d, --duration <T> Duration of test
-t, --threads <N> Number of threads to use
-s, --script <S> Load Lua script file
-H, --header <H> Add header to request
--latency Print latency statistics
--timeout <T> Socket/request timeout
-v, --version Print version details
Numeric arguments may include a SI unit (1k, 1M, 1G)
Time arguments may include a time unit (2s, 2m, 2h)
常用的参数有下面这些：
然后，我们来看一个wrk的测试结果，并对结果进行解析。
一个简单的测试如下（确保iam-apiserver已经启动，并且开启了健康检查）：
$ wrk -t144 -c30000 -d30s -T30s --latency http://10.0.4.57:8080/healthz
Running 30s test @ http://10.0.4.57:8080/healthz
144 threads and 30000 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 508.77ms 604.01ms 9.27s 81.59%
Req/Sec 772.48 0.94k 10.45k 86.82%
Latency Distribution
50% 413.35ms
75% 948.99ms
90% 1.33s
99% 2.44s
2276265 requests in 30.10s, 412.45MB read
Socket errors: connect 1754, read 40, write 0, timeout 0
Requests/sec: 75613.16
Transfer/sec: 13.70MB
下面是对测试结果的解析。
接下来，我们就来测试下API Server的性能。影响API Server性能的因素有很多，除了iam-apiserver自身的原因之外，服务器的硬件和配置、测试方法、网络环境等都会影响。为了方便你对照性能测试结果，我给出了我的测试环境配置，你可以参考下。
CentOS Linux release 8.2.2004 (Core)。CentOS Linux release 8.2.2004 (Core)。测试架构如下图所示：
在做API Server的性能测试时，需要先执行wrk，生成性能测试数据。为了能够更直观地查看性能数据，我们还需要以图表的方式展示这些性能数据。这一讲，我使用 gnuplot 工具来自动化地绘制这些性能图，为此我们需要确保Linux服务器已经安装了 gnuplot 工具。你可以通过以下方式安装：
$ sudo yum -y install gnuplot
在这一讲的测试中，我会绘制下面这两张图，通过它们来观测和分析API Server的性能。
X轴为并发数（Concurrent），Y轴为每秒查询数（QPS）和请求响应时间（TTLB）。X轴为并发数（Concurrent），Y轴为请求成功率。为了方便你测试API接口性能，我将性能测试和绘图逻辑封装在scripts/wrktest.sh脚本中，你可以在iam源码根目录下执行如下命令，生成性能测试数据和性能图表：
$ scripts/wrktest.sh http://10.0.4.57:8080/healthz
上面的命令会执行性能测试，记录性能测试数据，并根据这些性能测试数据绘制出QPS和成功率图。
接下来，我再来介绍下wrktest.sh性能测试脚本，并给出一个使用示例。
wrktest.sh性能测试脚本，用来测试API Server的性能，记录测试的性能数据，并根据性能数据使用gnuplot绘制性能图。
wrktest.sh也可以对比前后两次的性能测试结果，并将对比结果通过图表展示出来。wrktest.sh会根据CPU的核数自动计算出适合的wrk启动线程数（-t）：CPU核数 * 3。
wrktest.sh默认会测试多个并发下的API性能，默认测试的并发数为200 500 1000 3000 5000 10000 15000 20000 25000 50000。你需要根据自己的服务器配置选择测试的最大并发数，我因为服务器配置不高（主要是8G内存在高并发下，很容易就耗尽），最大并发数选择了50000。如果你的服务器配置够高，可以再依次尝试下测试 100000 、200000 、500000 、1000000 并发下的API性能。
wrktest.sh的使用方法如下：
$ scripts/wrktest.sh -h
Usage: scripts/wrktest.sh [OPTION] [diff] URL
Performance automation test script.
URL HTTP request url, like: http://10.0.4.57:8080/healthz
diff Compare two performance test results
OPTIONS:
-h Usage information
-n Performance test task name, default: apiserver
-d Directory used to store performance data and gnuplot graphic, default: _output/wrk
Reprot bugs to <colin404@foxmail.com>.
wrktest.sh提供的命令行参数介绍如下。
下面，我来展示一个wrktest.sh使用示例。
wrktest.sh的主要功能有两个，分别是运行性能测试并获取结果和对比性能测试结果。下面我就分别介绍下它们的具体使用方法。
执行如下命令：
$ scripts/wrktest.sh http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 200 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 500 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 1000 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 3000 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 5000 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 10000 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 15000 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 20000 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 25000 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 50000 http://10.0.4.57:8080/healthz
Now plot according to /home/colin/_output/wrk/apiserver.dat
QPS graphic file is: /home/colin/_output/wrk/apiserver_qps_ttlb.png
Success rate graphic file is: /home/colin/_output/wrk/apiserver_successrate.pngz
上面的命令默认会在_output/wrk/目录下生成3个文件：
这里要注意，请求URL中的IP地址应该是腾讯云VPC内网地址，因为通过内网访问，不仅网络延时最低，而且还最安全，所以真实的业务通常都是内网访问的。
假设我们还有另外一次API性能测试，测试数据保存在 _output/wrk/http.dat 文件中。
执行如下命令，对比两次测试结果：
$ scripts/wrktest.sh diff _output/wrk/apiserver.dat _output/wrk/http.dat
apiserver.dat和http.dat是两个需要对比的Wrk性能数据文件。上述命令默认会在_output/wrk目录下生成下面这两个文件：
在测试之前，我们需要关闭一些Debug选项，以免影响性能测试。
执行下面这两步操作，修改iam-apiserver的配置文件：
server.mode设置为release，server.middlewares去掉dump、logger中间件。log.level设置为info，log.output-paths去掉stdout。因为我们要在执行压力测试时分析程序的性能，所以需要设置feature.profiling为true，以开启性能分析。修改完之后，重新启动iam-apiserver。
关闭Debug配置选项之后，就可以执行wrktest.sh命令测试API性能了（默认测试的并发数为200 500 1000 3000 5000 10000 15000 20000 25000 50000）:
$ scripts/wrktest.sh http://10.0.4.57:8080/healthz
生成的QPS & TTLB图和成功率图分别如下图所示：
上图中，X轴为并发数（Concurrent），Y轴为每秒查询数（QPS）和请求响应时间（TTLB）。
上图中，X轴为并发数（Concurrent），Y轴为请求成功率。
通过上面两张图，你可以看到，API Server在并发数为200时，QPS最大；并发数为500，平均响应时间为56.33ms，成功率为 100.00% 。在并发数达到1000时，成功率开始下降。一些详细数据从图里看不到，你可以直接查看apiserver.dat文件，里面记录了每个并发下具体的QPS、TTLB和成功率数据。
现在我们有了API Server的性能数据，那么该API Server的QPS处于什么水平呢？一方面，你可以根据自己的业务需要来对比；另一方面，可以和性能更好的Web框架进行对比，总之需要有个参照。
这里用net/http构建最简单的HTTP服务器，使用相同的测试工具和测试服务器，测试性能并作对比。HTTP服务源码为（位于文件tools/httptest/main.go中）：
package main
import (
"fmt"
"log"
"net/http"
)
func main() {
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
message := `{"status":"ok"}`
fmt.Fprint(w, message)
})
addr := ":6667"
fmt.Printf("Serving http service on %s\n", addr)
log.Fatal(http.ListenAndServe(addr, nil))
}
我们将上述HTTP服务的请求路径设置为/healthz，并且返回{"status":"ok"}，跟API Server的接口返回数据完全一样。通过这种方式，你可以排除因为返回数据大小不同而造成的性能差异。
可以看到，该HTTP服务器很简单，只是利用net/http包最原生的功能，在Go中几乎所有的Web框架都是基于net/http包封装的。既然是封装，肯定比不上原生的性能，所以我们要把它跟用net/http直接启动的HTTP服务接口的性能进行对比，来衡量我们的API Server性能。
我们需要执行相同的wrk测试，并将结果跟API Server的测试结果进行对比，将对比结果绘制成对比图。具体对比过程可以分为3步。
第一步，启动HTTP服务。
在iam源码根目录下执行如下命令：
$ go run tools/httptest/main.go
第二步，执行wrktest.sh脚本，测试该HTTP服务的性能：
$ scripts/wrktest.sh -n http http://10.0.4.57:6667/healthz
上述命令会生成 _output/wrk/http.dat 文件。
第三步，对比两次性能测试数据：
$ scripts/wrktest.sh diff _output/wrk/apiserver.dat _output/wrk/http.dat
生成的两张对比图表，如下所示：
通过上面两张对比图，我们可以看出，API Server在QPS、响应时间和成功率上都不如原生的HTTP Server，特别是QPS，最大QPS只有原生HTTP Server 最大QPS的13.68%，性能需要调优。
上面，我们测试了API接口的性能，如果性能不合预期，我们还需要分析性能数据，并优化性能。
在分析前我们需要对API Server加压，在加压的情况下，API接口的性能才更可能暴露出来，所以继续执行如下命令：
$ scripts/wrktest.sh http://10.0.4.57:8080/healthz
在上述命令执行压力测试期间，可以打开另外一个Linux终端，使用go tool pprof工具分析HTTP的profile文件：
$ go tool pprof http://10.0.4.57:8080/debug/pprof/profile
执行完go tool pprof后，因为需要采集性能数据，所以该命令会阻塞30s。
在pprof交互shell中，执行top -cum查看累积采样时间，我们执行top30 -cum，多观察一些函数：
(pprof) top20 -cum
Showing nodes accounting for 32.12s, 39.62% of 81.07s total
Dropped 473 nodes (cum <= 0.41s)
Showing top 20 nodes out of 167
(pprof) top30 -cum
Showing nodes accounting for 11.82s, 20.32% of 58.16s total
Dropped 632 nodes (cum <= 0.29s)
Showing top 30 nodes out of 239
flat flat% sum% cum cum%
0.10s 0.17% 0.17% 51.59s 88.70% net/http.(*conn).serve
0.01s 0.017% 0.19% 42.86s 73.69% net/http.serverHandler.ServeHTTP
0.04s 0.069% 0.26% 42.83s 73.64% github.com/gin-gonic/gin.(*Engine).ServeHTTP
0.01s 0.017% 0.28% 42.67s 73.37% github.com/gin-gonic/gin.(*Engine).handleHTTPRequest
0.08s 0.14% 0.41% 42.59s 73.23% github.com/gin-gonic/gin.(*Context).Next (inline)
0.03s 0.052% 0.46% 42.58s 73.21% .../internal/pkg/middleware.RequestID.func1
0 0% 0.46% 41.02s 70.53% .../internal/pkg/middleware.Context.func1
0.01s 0.017% 0.48% 40.97s 70.44% github.com/gin-gonic/gin.CustomRecoveryWithWriter.func1
0.03s 0.052% 0.53% 40.95s 70.41% .../internal/pkg/middleware.LoggerWithConfig.func1
0.01s 0.017% 0.55% 33.46s 57.53% .../internal/pkg/middleware.NoCache
0.08s 0.14% 0.69% 32.58s 56.02% github.com/tpkeeper/gin-dump.DumpWithOptions.func1
0.03s 0.052% 0.74% 24.73s 42.52% github.com/tpkeeper/gin-dump.FormatToBeautifulJson
0.02s 0.034% 0.77% 22.73s 39.08% github.com/tpkeeper/gin-dump.BeautifyJsonBytes
0.08s 0.14% 0.91% 16.39s 28.18% github.com/tpkeeper/gin-dump.format
0.21s 0.36% 1.27% 16.38s 28.16% github.com/tpkeeper/gin-dump.formatMap
3.75s 6.45% 7.72% 13.71s 23.57% runtime.mallocgc
...
因为top30内容过多，这里只粘贴了耗时最多的一些关联函数。从上面的列表中，可以看到有ServeHTTP类的函数，这些函数是gin/http自带的函数，我们无需对此进行优化。
还有这样一些函数：
.../gin.(*Context).Next (inline)
.../internal/pkg/middleware.RequestID.func1
.../internal/pkg/middleware.Context.func1
github.com/gin-gonic/gin.CustomRecoveryWithWriter.func1
.../internal/pkg/middleware.LoggerWithConfig.func1
.../internal/pkg/middleware.NoCache
github.com/tpkeeper/gin-dump.DumpWithOptions.func1
可以看到，middleware.RequestID.func1、middleware.Context.func1、gin.CustomRecoveryWithWriter.func1、middleware.LoggerWithConfig.func1等，这些耗时较久的函数都是我们加载的Gin中间件。这些中间件消耗了大量的CPU时间，所以我们可以选择性加载这些中间件，删除一些不需要的中间件，来优化API Server的性能。
假如我们暂时不需要这些中间件，也可以通过配置iam-apiserver的配置文件，将server.middlewares设置为空或者注释掉，然后重启iam-apiserver。重启后，再次执行wrktest.sh测试性能，并跟原生的HTTP Server性能进行对比，对比结果如下面2张图所示：
可以看到，删除无用的Gin中间件后，API Server的性能有了很大的提升，并发数为200时性能最好，此时QPS为47812，响应时间为4.33``ms，成功率为100.00``%。在并发数为50000的时候，其QPS是原生HTTP Server的75.02%。
不同团队对API接口的性能要求不同，同一团队对每个API接口的性能要求也不同，所以并没有一个统一的数值标准来衡量API接口的性能，但可以肯定的是，性能越高越好。我根据自己的研发经验，在这里给出一个参考值（并发数可根据需要选择），如下表所示：
在进行API Server性能测试时，要考虑到API Server的性能影响因素。影响API Server性能的因素很多，大致可以分为两类，分别是Web框架的性能和API接口的性能。另外，在做性能测试时，还需要确保测试环境是一致的，最好是一个干净的测试环境。
Web框架的性能至关重要，因为它会影响我们的每一个API接口的性能。
在设计阶段，我们会确定所使用的Web框架，这时候我们需要对Web框架有个初步的测试，确保我们选择的Web框架在性能和稳定性上都足够优秀。当整个Go后端服务开发完成之后，在上线之前，我们还需要对Web框架再次进行测试，确保按照我们最终的使用方式，Web框架仍然能够保持优秀的性能和稳定性。
我们通常会通过API接口来测试Web框架的性能，例如健康检查接口/healthz。我们需要保证该API接口足够简单，API接口里面不应该掺杂任何逻辑，只需要象征性地返回一个很小的返回内容即可。比如，这一讲中我们通过/healthz接口来测试Web框架的性能：
s.GET("/healthz", func(c *gin.Context) {
core.WriteResponse(c, nil, map[string]string{"status": "ok"})
})
接口中只调用了core.WriteResponse函数，返回了{"status":"ok"}。这里使用core.WriteResponse函数返回请求数据，而不是直接返回ok字符串，这样做是为了保持API接口返回格式统一。
除了测试Web框架的性能，我们还可能需要测试某些重要的API接口，甚至所有API接口的性能。为了测试API接口在真实场景下的接口性能，我们会使用wrk这类HTTP压力测试工具，来模拟多个API请求，进而分析API的性能。
因为会模拟大量的请求，这时候测试写类接口，例如Create、Update、Delete等会存在一些问题，比如可能在数据库中插入了很多数据，导致磁盘空间被写满或者数据库被压爆。所以，针对写类接口，我们可以借助单元测试，来测试其性能。根据我的开发经验，写类接口通常不会有性能问题，反而读类接口更可能遇到性能问题。针对读类接口，我们可以使用wrk这类HTTP压力测试工具来进行测试。
在做性能/压力测试时，为了不影响生产环境，要确保在测试环境进行压测，并且测试环境的网络不能影响到生产环境的网络。另外，为了更好地进行性能对比和分析，也要保证我们的测试方法和测试环境是一致的。这就要求我们最好将性能测试自动化，并且每次在同一个测试环境进行测试。
在项目上线前，我们需要对API接口进行性能测试。通常API接口的性能延时要小于 500ms ，如果大于这个值，需要考虑优化性能。在进行性能测试时，需要确保每次测试都有一个一致的测试环境，这样不同测试之间的数据才具有可对比性。这一讲中，我推荐了一个比较优秀的性能测试工具 wrk ，我们可以编写shell脚本，将wrk的性能测试数据自动绘制成图，方便我们查看、对比性能。
如果发现API接口的性能不符合预期，我们可以借助 go tool pprof 工具来分析性能。在 go tool pprof 交互界面，执行 top -cum 命令查看累积采样时间，根据累积采样时间确定影响性能的代码，并优化代码。优化后，再进行测试，如果不满足，继续分析API接口的性能。如此往复，直到API接口的性能满足预期为止。
欢迎你在留言区与我交流讨论，我们下一讲见。