简述性能测试
提起性能测试，可能移动APP的从业人员会感觉比较混淆，因为在客户端（Android、iOS）中也有性能测试专项，主要涉及的是APP的启动时间、内存、包大小、帧率，流量等客户端相关的指标。在本博客之前的文章中，也包含了一些客户端性能测试的内容。需要说明的是，本文所讲解的性能测试都是针对服务器端，尤指Web系统的，与移动APP的性能测试完全是不同的领域。
那么，什么是服务端的性能测试呢？
先从大家都熟悉的功能测试说起吧。例如，我们要测试一个搜索功能，那么我们测试时，就会输入搜索关键词，点击搜索按钮，然后再去查看搜索结果，看结果是否跟我们输入的搜索关键词匹配，如果匹配则说明搜索功能实现正确。
那如何对该功能进行性能测试呢？
答案就是，N个人同时进行功能性操作的同时，在确保功能实现正确的前提下，考察服务端应用程序的各项性能指标，以及服务器硬件资源的使用情况。
当然，这个答案比较简单粗暴，但是它仍然包含了性能测试的基本特点：
- 以功能实现正确为前提
- 通常有一定的并发用户
- 重点考察服务器端在一定并发压力下的性能指标
最后，再明确下性能测试的目的。通常，对服务器端应用程序开展性能测试，是为了验证软件系统是否能够达到预期的性能指标，同时发现软件系统中存在的性能瓶颈，从而实现优化系统的目的。
性能测试方法的核心
根据不同的测试目的，性能测试可以分为多种类型，常见的有如下几类：
- 基准测试（Standard Testing）
- 负载测试（Load Testing）
- 压力测试（Stress Testing）
- 疲劳强度测试
首先说下基准测试。基准测试指的是模拟单个用户执行业务场景时，考察系统的性能指标。严格意义上来讲，基准测试并不能算作性能测试范畴，它跟功能测试并没有太大区别。差异在于，基准测试的目的更多地是关注业务功能的正确性，或者说验证测试脚本的正确性，然后，将基准测试时采集得到的系统性能指标，作为基准测试结果，为后续并发压力测试的性能分析提供参考依据。
负载测试，主要指的是模拟系统在正常负载压力场景下，考察系统的性能指标。这里说的正常负载，主要是指用户对系统能承受的最大业务负载量的期望值，即预计系统最大应该支持多大用户的并发量。通过负载测试，目的是验证系统是否能满足预期的业务压力场景。
和负载测试的概念比较接近的是压力测试。通俗地讲，压力测试是为了发现在多大并发压力下系统的性能会变得不可接受，或者出现性能拐点（崩溃）的情况。在加压策略上，压力测试会对被测系统逐步加压，在加压的过程中考察系统性能指标的走势情况，最终找出系统在出现性能拐点时的并发用户数，也就是系统支持的最大并发用户数。
最后再说下疲劳强度测试。其实疲劳强度测试的加压策略跟负载测试也很接近，都是对系统模拟出系统能承受的最大业务负载量，差异在于，疲劳强度测试更关注系统在长时间运行情况下系统性能指标的变化情况，例如，系统在运行一段时间后，是否会出现事务处理失败、响应时间增长、业务吞吐量降低、CPU/内存资源增长等问题。
通过对比可以发现，不同的性能测试类型，其本质的差异还是在加压策略上，而采用何种加压策略，就取决于我们实际的测试目的，即期望通过性能测试发现什么问题。明白了这一点，性能测试类型的差异也就不再容易混淆了。
结论要点1：性能测试手段的重点在于加压的方式和策略。
性能瓶颈定位的核心
在前面频繁地提到了性能指标，那性能指标究竟有哪些，我们在性能测试的过程中需要重点关注哪些指标项呢？
从维度上划分，性能指标主要分为两大类，分别是业务性能指标和系统资源性能指标。
业务性能指标可以直观地反映被测系统的实际性能状况，常用的指标项有：
- 并发用户数
- 事务吞吐率（TPS/RPS）
- 事务平均响应时间
- 事务成功率
而系统资源性能指标，主要是反映整个系统环境的硬件资源使用情况，常用的指标包括：
- 服务器：CPU利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘IO状态、网卡带宽使用情况等；
- 数据库：数据库连接数、数据库读写响应时长、数据库读写吞吐量等；
- 网络：网络吞吐量、网络带宽、网络缓冲池大小；
- 缓存（Redis）：静态资源缓存命中率、动态数据缓存命中率、缓存吞吐量等；
- 测试设备（压力发生器）：CPU利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘IO状态、网卡带宽使用情况等。
对于以上指标的具体含义我就不在此进行逐一说明了，大家可以自行搜索，务必需要搞清楚每个指标的概念及其意义。可能有些指标在不同的操作系统中的名称有些差异，但是基本都会有对应的指标，其代表的意义也是相通的。例如，处理器队列长度这个指标，在Windows中的指标名称是SystemProcessor Queue Length，而在Linux系统中则需要看load averages。
可能对于最后一项（测试设备）有些人不大理解，监控被测系统环境的相关硬件资源使用情况不就好了么，为什么还要关注测试设备本身呢？这是因为测试设备在模拟高并发请求的过程中，设备本身也会存在较高的资源消耗，例如CPU、内存、网卡带宽吃满，磁盘IO读写频繁，处理器排队严重等；当出现这类情况后，测试设备本身就会出现瓶颈，无法产生预期的并发压力，从而我们测试得到的数据也就不具有可参考性了。此处暂不进行展开，后面我会再结合实际案例，通过图表和数据对此详细进行说明。
需要说明的是，性能指标之间通常都是有密切关联的，单纯地看某个指标往往很难定位出性能瓶颈，这需要我们对各项性能指标的含义了然于胸，然后才能在实际测试的过程中对系统性能状况综合进行分析，找出整个系统真正的瓶颈。举个简单的例子，压力测试时发现服务器端CPU利用率非常高，那这个能说明什么问题呢？是服务端应用程序的算法问题，还是服务器硬件资源配置跟不上呢？光看这一个指标并不能定位出产生问题的真正原因，而如果仅因为这一点，就决定直接去优化程序算法或者升级服务器配置，最后也很难真正地解决问题。
结论要点2：性能瓶颈定位的重点在于性能指标的监控和分析。
引入性能测试工具
通过前面的讲解，我们已经知道性能测试的主要手段是通过产生模拟真实业务的压力对被测系统进行加压，与此同时监控被测系统的各项性能指标，研究被测系统在不同压力情况下的表现，找出其潜在的性能瓶颈。
那么，如何对系统进行加压，又如何对系统的指标进行监控呢？这里，就需要引入性能测试工具了。
当然，我们也可以先看下在不借助性能测试工具的情况下，如何手工地对系统进行性能测试。
假设现在我们要对前面提到的搜索功能进行负载测试，验证在20个并发用户下搜索功能的事务平均响应时间是否在3秒以内。
很自然地，我们可以想到测试的必要条件有如下几点：
- 20个测试人员，产生业务压力
- 1个指挥人员，对20个人员的协调控制，实现并发操作
- 1个结果记录人员，对每一个人员的操作耗时进行监控和记录
- 若干资源监控人员，实时查看被测系统的各项性能指标，对指标进行汇总、分析
- 1个结果统计人员，对20个用户各操作消耗的时长进行汇总，计算其平均值
可以看出，要通过人工来进行性能测试，操作上极为繁琐，需要投入的资源非常多，而这还仅仅是一个非常简单的场景。设想，如果要测试10000并发，服务器有好几十台，显然，这种情况下是完全不可能通过投入人力就能解决的。这也就是性能测试工具存在的必要性和诞生的背景。
性能测试工具的基本组成
当前，市面上已经有了很多性能测试工具，但不管是哪一款，基本都会包含如下几个核心的模块。
- 压力生成器（Virtual User Generator）
- 结果采集器（Result Collector）
- 负载控制器（Controller）
- 系统资源监控器（Monitor）
- 结果分析器（Analysis）
原理结构图如下所示：
对照前面手工进行性能测试的案例，不难理解，压力发生器对应的是众多测试人员，结果采集器对应的是结果记录人员，负载控制器对应的是指挥人员，资源监控器对应的是若干资源监控人员，结果分析器对应的是结果统计人员。
其中，压力发生器又是性能测试工具最核心的部分，它主要有两个功能，一是真实模拟用户操作，二是模拟有效并发。
然而，大多数性能测试工作人员可能都会忽略的是，当前市面上性能测试工具的压力发生器基本都是存在缺陷的。
先说下模拟真实用户操作。如果熟悉浏览器的工作原理，就会知道浏览器在加载网页的时候，是同时并发多个TCP连接去请求页面对应的HTTP资源，包括HTML、JS、图片、CSS，当前流行的浏览器普遍会并发6-10个连接。然而，性能测试工具在模拟单个用户操作的时候，基本上都是单连接串行加载页面资源。产生的差异在于，假如页面有100个资源，每个HTTP请求的响应时间约为100毫秒，那么浏览器采用6个连接并行加载网页时大概会需要1.7秒（100/6*100毫秒），而测试工具采用单连接串行加载就需要10秒（100*100毫秒），两者结果相差十分巨大。这也解释了为什么有时候我们通过性能测试工具测试得到的响应时间挺长，但是手动用浏览器加载网页时感觉挺快的原因。
再说下有效并发。什么叫有效并发？有效并发就是我们在测试工具中设置了1000虚拟用户数，实际在服务器端就能产生1000并发压力。然而现实情况是，很多时候由于测试设备自身出现了性能瓶颈，压力发生器产生的并发压力远小于设定值，并且通常测试工具也不会将该问题暴露给测试人员；如果测试人员忽略了这个问题，以为测试得到的结果就是在设定并发压力下的结果，那么最终分析得出的结论也就跟实际情况大相径庭了。不过，我们可以通过保障测试环境不存在瓶颈，使得实际生成的并发压力尽可能地与设定值一致；另一方面，我们也可以通过在测试过程中监控Web层（例如Nginx）的连接数和请求数，查看实际达到服务器端的并发数是否跟我们的设定值一致，以此来反推压力发生器的压力是否有效。
了解这些缺陷的意义在于，我们可以更清楚测试工具的原理，从而更准确地理解测试结果的真实含义。
性能测试工具推荐
经过充分的理论铺垫，现在总算可以进入正题，开始讲解工具部分了。
在性能测试工具方面，我重点向大家推荐Locust这款开源工具。目前阶段，该款工具在国内的知名度还很低，大多数测试人员可能之前都没有接触过。为了便于理解，我先将Locust与LoadRunner、Jmeter这类大众耳熟能详的性能测试工具进行简单对比。
| LoadRunner | Jmeter | Locust | |
|---|---|---|---|
| 授权方式 | 商业收费 | 开源免费 | 开源免费 |
| 开发语言 | C/Java | Java | Python |
| 测试脚本形式 | C/Java | GUI | Python |
| 并发机制 | 进程/线程 | 线程 | 协程 |
| 单机并发能力 | 低 | 低 | 高 |
| 分布式压力 | 支持 | 支持 | 支持 |
| 资源监控 | 支持 | 不支持 | 不支持 |
| 报告与分析 | 完善 | 简单图表 | 简单图表 |
| 支持二次开发 | 不支持 | 支持 | 支持 |
通过对比，大家可能会疑惑，Locust也不怎么样嘛，资源监控也不支持，报告分析能力也这么弱，那为啥还要选择它呢？
授权方式这个就不说了。虽然LoadRunner是商业软件，价格极其昂贵，但是国内盗版横行，别说个人，就算是大型互联网公司，用正版的也没几个。
从功能特性的角度来讲，LoadRunner是最全面的，用户群体也是最多的，相应的学习资料也最为丰富。个人建议如果是新接触性能测试，可以先熟悉LoadRunner，借此了解性能测试工具各个模块的概念和功能，在此基础上再转到别的测试工具，也都比较好上手了。不过，LoadRunner只能在Windows平台使用，并且并发效率比较低，单台压力机难以产生较高的并发能力，这也是现在我弃用该款工具的主要原因。
同样地，Jmeter的并发机制也是基于线程，并发效率存在同样的问题；另外，Jmeter在脚本编写和描述方面是基于GUI操作，个人感觉操作比较繁琐（这个因人而异），因此不是很喜欢。
那么，我重点推荐的Locust有啥特别的地方呢？
如果从整体功能上来看的话，Locust的功能的确比较单薄。不过，作为性能测试工具最核心的压力发生器部分，却是非常不错的。抛开官方文档的介绍，个人觉得最赞的有两点。
首先是模拟用户操作，也就是测试脚本描述方面。Locust采用Pure Python脚本描述，并且HTTP请求完全基于Requests库。用过Requests的都知道，这个库非常简洁易用，但功能十分强大，很多其它编程语言的HTTP库都借鉴了它的思想和模式，如果将其评选为最好用的HTTP库之一（不限语言），应该也不会有太大的争议。除了HTTP(S)协议，Locust也可以测试其它任意协议的系统，只需要采用Python调用对应的库进行请求描述即可。
另外一点就是并发机制了。Locust的并发机制摒弃了进程和线程，采用协程（gevent）的机制。采用多线程来模拟多用户时，线程数会随着并发数的增加而增加，而线程之间的切换是需要占用资源的，IO的阻塞和线程的sleep会不可避免的导致并发效率下降；正因如此，LoadRunner和Jmeter这类采用进程和线程的测试工具，都很难在单机上模拟出较高的并发压力。而协程和线程的区别在于，协程避免了系统级资源调度，由此大幅提高了性能。正常情况下，单台普通配置的测试机可以生产数千并发压力，这是LoadRunner和Jmeter都无法实现的。
有了一个不错的引擎，外表装饰简陋点也都是可以接受的了。不过虽然Locust功能单薄，特别是在性能指标监控和测试报告图表方面比较缺失，但是Locust的代码结构清晰，核心代码量也只有几百行，可扩展性也非常不错。换言之，Locust的可玩性（hackable）极强，对于一个想深入挖掘性能测试工具原理的人来说，Locust非常适合。
好了，Locust的介绍暂且到这儿，后续我会再对Locust的使用方法和二次开发进行详细介绍，也算是弥补官方文档的不足吧。