# 29 | 最容易失准的性能测试?你需要压测工具界的“悍马”wrk 你好,我是温铭。 在测试章节的最后一节课,我和你来聊聊性能测试。这部分内容并非 OpenResty 独有,对于其他的后端服务来说,都是一样适用的。 性能测试很常见,在我们交付产品的时候,都会带有性能指标的要求,比如 QPS、TPS 达到多少,延时要低于多少毫秒,可以并发支持多少用户的连接等等。对于开源项目而言,我们发版本之前也会做一次性能测试,和上一个版本对比,看是否有明显的衰退。也有一些中立的网站,会发布同类产品的性能对比数据。不得不说,性能测试离我们真的很近。 在我的十几年的工作中,针对不同的产品做过很多次性能测试,中间也踩过不少坑。后来,我逐渐地发现,性能测试做起来简单,但做对却并不容易,甚至可以说,很多性能测试的结果都是失准的。 那么,如何做一个科学严谨的性能测试呢?今天这节课,且听我娓娓道来。 ## 性能测试工具 工欲善其事,必先利其器。选择一个趁手的性能测试工具,是成功的一半。 `ab` 这个 Apache Benchmark 工具你应该很熟悉,可以说是最简单的性能测试工具,但可惜的是并不好用。这是因为,当前服务端基本都基于协程和异步 I/O 来开发,性能不差;而 ab 利用不到机器的多核,生成的请求压力不够大。这种情况下,ab 测试得到的结果,并不真实,反而变成了 ab 自身的性能测试。 所以,我们可以明确选择压测工具的一个标准,那就是:**工具自身的性能非常强悍,可以生成足够大的压力,压垮服务端程序。** 当然,你也可以有钱任性,启动很多压测客户端,变为分布式压测系统。这自然是可行的,但不要忘记,与此同时的复杂度也跟着上去了。 回到 OpenResty 的实践,我们推荐使用的性能测试工具是 wrk。先来说说,为什么选择它呢? 首先, wrk 满足工具选型的标准。单机的 wrk 产生的压力,可以轻松让 Nginx 跑满 CPU,其他服务端程序更是不在话下。 其次, wrk 和 OpenResty 有很多类似的地方。wrk 也不是从零开始编写的一个开源项目,它站在 LuaJIT 和 Redis 这两个巨人的肩膀上,充分利用了系统的多核资源来生成请求。除此之外,wrk 还暴露了 Lua API,你可以嵌入自己的 Lua 脚本,来自定义请求的头和内容,使用非常灵活。 那么该如何使用 wrk呢?也很简单,看下面这段代码的内容: ``` wrk -t12 -c400 -d30s http://127.0.0.1:8080/index.html ``` 这意味着 wrk 会使用 12 个线程,保持 400 个长连接,持续 30 秒钟,来给指定的 API 接口发送 HTTP 请求。当然,如果你不指定参数的话,wrk 会默认启动 2 个线程和 10 个长连接。 ## 测试环境 找好测试工具后,我们还不能直接开始压力测试,还需要把测试环境给检查一遍,测试环境需要检查的主要有四项,下面我分别来详细讲讲。 ### 检查项一:关闭 SELinux 如果你是 CentOS/RedHat 系列的操作系统,建议你关闭 SELinux,不然可能会遇到不少诡异的权限问题。 我们通过下面这个命令,查看 SELinux 是否开启: ``` $ sestatus SELinux status: disabled ``` 如果显示是开启的(enforcing),你可以通过`$ setenforce 0`来临时关闭;同时修改 `/etc/selinux/config` 文件来永久关闭,将 `SELINUX=enforcing` 改为 `SELINUX=disabled`。 ### 检查项二:最大打开文件数 然后,你需要用下面的命令,查看下当前系统的全局最大打开文件数: ``` $ cat /proc/sys/fs/file-nr 3984 0 3255296 ``` 这里的最后一个数字,就是最大打开文件数。如果你的机器中这个数字比较小,那就需要修改 `/etc/sysctl.conf` 文件来增大: ``` fs.file-max = 1020000 net.ipv4.ip_conntrack_max = 1020000 net.ipv4.netfilter.ip_conntrack_max = 1020000 ``` 修改完以后,还需要重启系统服务来生效: ``` sudo sysctl -p /etc/sysctl.conf ``` ### 检查项三:进程限制 除了系统的全局最大打开文件数,一个进程可以打开的文件数也是有限制的,你可以通过命令 `ulimit` 来查看: ``` $ ulimit -n 1024 ``` 你会发现,这个值默认是 1024,是一个很低的数值。因为每一个用户请求都会对应着一个文件句柄,而压力测试会产生大量的请求,所以我们需要增大这个数值,把它改为百万级别,你可以用下面的命令来临时修改: ``` $ ulimit -n 1024000 ``` 也可以修改配置文件 `/etc/security/limits.conf` 来永久生效: ``` * hard nofile 1024000 * soft nofile 1024000 ``` ### 检查项四:Nginx 配置 最后,你还需要对 Nginx 的配置,做一个小的修改,也就是下面这两行代码的操作: ``` events { worker_connections 10240; } ``` 这样,我们就可以把每个 worker 的连接数增大了。因为它的默认值只有 512,这在大压力的测试下显然是不够的。 ## 压测前检查 到此为止,测试环境已经准备好了。一定有人蠢蠢欲动想要上手测试了吧?且慢,在使用 wrk 发起测试之前,让我们最后再来检测一次。毕竟,人总会犯错,换个角度来做一次交叉测试,是非常重要的。 最后的这次检测,可以分为两步。 ### 第一步,使用自动化工具 `c1000k`。 它来自 SSDB 的作者:[https://github.com/ideawu/c1000k](https://github.com/ideawu/c1000k)。从名字你就能看出来,这个工具的目的,就是用来检测你的环境是否可以满足100万并发连接的要求。 这个工具的使用也很简单。我们分别启动一个 server 和 client,对应着监听 7000 端口的服务端程序,以及发起压力测试的客户端程序,目的是为了模拟真实环境下的压力测试: ``` ./server 7000 ./client 127.0.0.1 7000 ``` 紧接着,client 会向 server 发送请求,检测当前的系统环境能否支持 100 万并发连接。你可以自己去运行一下,看看结果。 ### 第二步,检测服务端程序是否正常运行。 如果服务端的程序不正常,那么压力测试可能就成了错误日志刷新测试,或者是 404 响应测试。 所以,测试环境检测的最后一步,也是最重要的一步,就是**跑一遍服务端的单元测试集,或者手动调用几个主要的接口,来保证 wrk 测试的所有接口、返回的内容和 http 响应码都正常,并且在 `logs/error.log` 中没有出现任何错误级别的信息。** ## 发送请求 好了,到现在,万事俱备,只欠东风了。让我们开始用 wrk 来做压力测试吧! ``` $ wrk -d 30 http://127.0.0.2:9080/hello Running 30s test @ http://127.0.0.2:9080/hello 2 threads and 10 connections Thread Stats Avg Stdev Max +/- Stdev Latency 595.39us 178.51us 22.24ms 90.63% Req/Sec 8.33k 642.91 9.46k 59.80% 499149 requests in 30.10s, 124.22MB read Requests/sec: 16582.76 Transfer/sec: 4.13MB ``` 这里,我并没有指定参数,所以wrk会默认启动 2 个线程和 10 个长连接。其实,你也并不需要把wrk 的线程数和连接数调整得很大,只要能够让目标程序跑满 CPU 就达到要求了。 但压测的时间一定不能太短,几秒钟的压测是没有意义的,不然很有可能服务端的程序还没加载完热数据,压测就已经结束了。同时,在压测期间,你需要使用 top 或者 htop 这样的监控工具,来确认服务端目标程序是否跑满 CPU。 从现象上来看,如果 CPU 满载,而且压测停止后,CPU 和内存占用迅速降低,那么恭喜你,这次压测顺利完成。但如果有下面这样的异常,作为服务端开发的你就得特别留意了。 * CPU 不能满载。这不会是 wrk 的问题,可能是网络的限制,更可能是你的代码中有阻塞的操作。你可以通过 review 代码来确定,也可以使用 off CPU 火焰图来确定。 * CPU 一直满载,即使压测停止仍然如此。这说明在代码中存在热循环,可能是正则表达式引起的,也可能是 LuaJIT 的 bug 引起的,这两点都是我在真实的环境中遇到过的问题。这时,你就需要用 on CPU 火焰图来确定了。 最后再来一起看下 wrk 的统计结果。关于这个结果,我们一般会关注两个值: 第一个是 QPS,也就是 `Requests/sec: 16582.76`,这个数据很直接,表示服务端每秒钟处理了多少请求。 第二个是延时 `Latency 595.39us 178.51us 22.24ms 90.63%`,这个数据和 QPS 一样重要,它体现了系统的响应速度。比如对于网关的应用来讲,我们就希望能够把延时控制在 1 毫秒以内。 另外, wrk 还提供了 latency 参数,可以把延时的分布百分比详细地打印出来,比如: ``` Latency Distribution 50% 134.00us 75% 180.00us 90% 247.00us 99% 552.00us ``` 不过,wrk 的延时分布数据并不准确,因为它人为地加入了网络和工具的扰动,放大了延时,这一点需要你特别注意。关于wrk Latency Distribution,你可以通过我以前写的[这篇文章](https://mp.weixin.qq.com/s/n8a4wzmf6I8kUc-T47PylA)来了解详细内容。 ## 写在最后 性能测试是个技术活儿,能做对、做好的人不多。希望今天这节课,能让你对性能测试有一个更全面的认识。 最后给你留一个作业题:wrk 支持自定义 Lua 脚本来做压力测试,那么,你可以根据它的文档,写一段简单的 Lua 脚本吗?这可能会有一些难度,但完成的同时,你一定能更深刻地理解 wrk 暴露接口的用意。 欢迎留言写下你的答案和思考,也欢迎你把这篇文章分享给更多的人,我们共同进步。