后端开发必备技能:压力测试的重要性

发表时间: 2019-08-04 11:00

专注于Java领域优质技术,欢迎关注

作者: 温增闽 来自:杏仁技术站

杏仁后端工程师,专注高并发和分布式编程,Golang爱好者。

压力测试必知必会

压力测试是后端程序员的必备技能,很多工作场景都需要用到这项技能,如果你还不会,那就现在马上学习实践起来,以便不时之需。

五分钟上手压测

1.安装压测工具:四分钟

提前安装好一个趁手的压测工具,Wrk 是现代的压测工具,小巧实用。

Wrk 是 C 语言写就的压测工具,所以编译安装需要花些时间,你懂的。(只能在类 Unix 操作系统安装

安装成功的话会显示 Wrk 的版本信息:

2.“一句话”压测:半分钟

简单尝试一下 Wrk 功能,如:

上面这条命令的含义:使用 1 个线程,创建 1 个并发连接,对百度首页进行 10 秒钟的压测,压测结束后打印出延迟分区报告。其中,每个参数的含义:

  • wrk:Wrk 压测工具压测命令。
  • -t:并发线程数量,这里简单设置为 1。
  • -c:并发连接数,这里简单设置为 1。
  • -d:压测时长,这里设置为 10 秒钟。
  • https://www.baidu.com 压测目标地址。
  • --latency 输出延迟分区报告。

3.“秒懂”压测报告:半分钟

上面的压测命令执行完成后,会输出压测报告,如下所示:

我们来逐行解读一下:

  • 第 1 行:压测时间和压测目标地址。
  • 第 2 行:线程数和并发连接数。
  • 第 3~5 行:平均每个线程的压测数据;第 3 行是标题,有平均值、标准差、最大值、正负标准差这 4 种统计方式;第 4 行是延迟数据;第 5 行是每秒请求数。
  • 第 6~10 行:延迟分区报告。当指定 --latency 参数时才会输出延迟分区报告。从 50%,75%,90%,99% 这 4 个区域统计延迟时间。所以叫延迟分区报告。
  • 第 11 行:请求数,压测时长,下行流量。
  • 第 12 行:每秒请求数,也就是每秒吞吐量,业界俗称 QPS
  • 第 13 行:每秒上行流量。

总的来说还是非常简单明了的,是不是?

理解压测关键指标

无论使用何种压测工具,每次压测后都可以得到这 3 个关键指标:并发连接数,吞吐量(QPS),延迟。

1.并发连接数

要理解并发连接数,首先要理解连接,它是指客户端向服务端发起请求时建立的 TCP 连接,那并发连接数就是在一段时间内客户端与服务端的 TCP 连接数。如,C10K问题,就是指服务端一秒能处理一万个连接的能力。

在压测中,并发连接数这个参数到底有什么意义?想象一下你正在车站排队买票,车站只开了一个售票窗口,队伍越来越长,车站里甚至出现了拥堵,站长看到拥堵的情况后增加了几个窗口,于是队伍迅速地缩短了几倍,你也很快买到了车票,车站人流也顺畅了很多。

你看,这就是并发窗口数发挥了作用。

并发窗口数与并发连接数是一样的道理,窗口数影响售票数,而连接数影响请求数。

所以,在压测时,我们可以通过增加并发连接数来增大压测的请求数,通过不断地加压来测试软件的最大处理能力。

这就像在举重比赛中,不断增加杠铃的重量,哪个选手能坚持到最后,就获得冠军。

2.吞吐量/请求数

吞吐量/请求数是指一段时间内,客户端向服务端发起请求并获得响应的数量。

3.延迟/响应时间

延迟/响应时间一般是指一段时间内,请求从发起到得到响应消耗的平均时间。

出于准确性的考虑,我们还会综合考量延迟分布情况,一般是从前 99%、前 90%、前 75%、前 50%这几个分区进行统计。进行分区统计的原因在于,当少数的慢请求延迟非常高时,会直接影响平均延迟,这时平均延迟就无法准确地反应整体响应指数了,所以分区统计提供了更全面可靠的参考系。

分析性能瓶颈

通过逐步增加并发连接数,在多次加压之后,我们可以绘制出“并发连接与吞吐量趋势图”,和“延迟与吞吐量趋势图”:

结合这两张图,我们能够很直观地解读出软件系统的性能瓶颈。

在“并发连接与吞吐量”的图中,吞吐量的峰顶处对应的并发连接数,就是系统能处理的极限并发连接数了。

而在“延迟与吞吐量”的图中,在吞吐量颓势未显时达到设定的最大延迟处,就是系统的最大吞吐量了。

下面来简单总结一下,并发连接数、吞吐量、延迟之间的关系:

  • 并发连接数与吞吐量成正比。如果随着并发数的增加,吞吐量不再提升甚至开始下降,说明已经达到系统吞吐量的极限值。
  • 吞吐量与响应延迟成正比。当响应时间触达阈值,此时的吞吐量为系统的极限值。
  • 吞吐量极限需要综合考虑并发连接数和延迟的数值。
  • 并发连接数是影响吞吐量的关键性变量,通过阶段性提高并发连接数测试出系统吞吐量的极限。
  • 当然,以上讨论的前提是,系统请求成功率符合预期(一般是 95% 以上)。

以上,就是压力测试的一些必知必会,聪明如你一定已经了然于心,当老板再问你系统的并连接数、吞吐量、延迟是多少?你能自豪地给出回答。(当然前提是你开发的系统性能经得起考验:)


最近无意中发现了一个巨牛的人工智能教程,忍不住分享一下给大家。教程不仅是零基础,通俗易懂,而且非常风趣幽默,像看小说一样!觉得太牛了,所以分享给大家。点这里可以跳转到教程。

https://www.captainbed.net/suga