BigHead、Peki等 逆熵研习社

服务端性能测试是针对服务端验证性能状况以及是否存在问题进行的测试，执行过程包括目标制定（确定需求）、测试准备、测试执行、测试结果分析等环节。除测试执行外其他环节也非常重要，精深的细节在后续专项中一一讨论，本文重点讨论下这个大过程每个阶段的目标以及要点。

确定性能测试目标

需求确认

明确目标或者需求是首要的事情，它关乎后面整个测试的准备与执行。以下是常见的目标

*衡量全系统的负载能力，评估下可以正常服务的负载范围。

*某个服务的极限压力，瓶颈点等。

*某个服务升级后性能是否变得糟糕。

还有些情况针对业务中的某些场景需要确认下性能状况的，比如用户登录，业务查询，电商的高并发交易等场景等。不管是上面概括性的描述还是具体场景的描述潜在的和目标相关的三个要素需要我们把它抽象出来：

1.在什么样的系统范围内进行验证，需要弄明白目标所指的被测系统范围——是整个业务系统还是业务系统的某一部分？

2.需要验证业务场景，根据这个业务场景我们需要找到用户可能发送的请求的集合。

3.需要达到的状态，是用户的并发状态，还是服务的极限压力状态等，这个是我们后面达到目标的一个关键标准。

在确定目标时还需要我们确定该目标是否合理，也就是能否满足最终的业务需求。举例子来说，如果业务重要目标是TPS在3万情况下服务正常，那目标就不能定为：验证系统的极限压力为3万，因为即使系统极限压力达到了3万用户的体验绝对算不上是正常的。

最后在整个性能测试的过程中需要我们要经常回顾下我们的取舍和方案是否能够满足最初的目标。

指标确定

确定了目标后，接下来要做的事情是将目标转化为性能测试本身验证的指标。这些指标即包含代表用户端体验的请求指标，也包含系统后端服务状态。下面给出了我们经常见到的指标：

系统容量：系统最大能容纳多少用户的操作? 通常业务系统的用户操作有多个流程，可以按照一定比例进行折算测试。

并发数：模拟并发用户数，一个系统中应该有不同的操作的并发数组合，尽可能模拟用户真实场景。响应时间：接口/用户操作的响应时间，如果时间比较长会影响用户体验，增大系统负载。

吞吐率：系统每秒处理的事务数量（TPS），和这个指标相关的指标是每秒钟处理的请求数（QPS）。这两者是什么关系呢？处理用户请求的事务包含一个或者多个请求，举个例子说用户通过验证码登陆这个事务就包含了用户获取验证码请求和用户发送登陆请求两个请求（如果每秒能够满足20个人同时登陆，那么对应的TPS就是20）。明白了这个逻辑我们就可以根据具体的场景测试出对应的吞吐量数据。

系统性能指标：服务器CPU，内存，IO，带宽使用情况等，这些指标是服务状态的重要指示。

测试准备

准备测试计划

确定了系统目标和指标，接下来还有一个事情就是需要准备下测试计划。计划是将最终目标分解成每步可以完成的子目标，例如下面的计划：

其中对于对于用户获取验证码登陆这个场景包含如下请求：

在测试开始前对具体的性能表现尚不十分清楚，所以测试计划体现主要测试路径即可，具体的压力计划可以根据测试中具体表现进行调整。

准备测试环境

测试环境的建设一般来讲比较复杂，需要根据具体业务场景和公司资源来选择，比如可以利用生产环境进行性能测试（需要考虑安全和后期的数据清理），也可使用线下环境测试，一般会尽可能选择和线上硬件资源比较类似的机器，便于对比分析。线下性能测试安全性会比较高，但有一定额外成本。

性能测试环境在建设过程中除去需要考虑业务本身的拓扑外还有技术性要素要考虑，例如数据库、缓存和队列如何模拟类似线上的状况。如果是做升级前后性能对比类测试性能环境只需做到类似线上部署即可，但要高度模拟线上的状况，需要考虑一下因素

1.硬件环境，除机器状况需要考虑外，网络状况等也需要重点考虑。

2.软件版本一致，包括操作系统、数据库、中间件以及被测系统等。

3.配置与线上一致，包括系统、中间件以及服务配置。

4.场景一致，数据、请求分布以及量级与线上一致（对于敏感数据可以通过脱敏处理）。

此外，性能测试环境中又一个非常头疼的问题是第三方以来服务的问题，使用线上第三方做压测大多数情况下是不允许的，因此做一个第三方性能MOCK是一个常用的方案，在这种方案中第三方请求的响应时间分布需要作为可配置项精心管理。

压测工具准备

性能测试工具非常多，比如ab，jmeter，loadrunner等，需要注意的是服务端性能测试的重点是测试设计，准备，以及后期的性能瓶颈分析上，绝不是掌握一个工具使用就是性能测试专家了。在压测工具选择上理论上保证能够快速达到预期的并发规模且压测工具本身不成为性能瓶颈即可。以下三种性能工具可以作为选择的参考：

Apache JMeter

优点：图形化，操作简单，带有cookie信息的请求，保存配置文件，功能强大。

缺点：扩展起来稍微复杂了些。

Http_Load

优点：并行复用的方式运行，可以以一个单一的进程运行，一般不会把客户机搞死。

缺点：测试结果分析有限，平台依赖linux。

Multi-Mechanize

优点：自定义脚本，可实现参数加密，结果呈现形式好

缺点：只能做负载测试，结果处理效率很低（测试1个小时，出结果就得半小时，数据生成图像时间较长）

其中Apache JMeter在日常测试中营运非常广泛，是一个专门为运行和服务器装载测试而设计的、100％的纯Java桌面运行程序。初期它是为Web/HTTP测试而设计的，但是它已经扩展以支持各种各样的测试模块。它和用于HTTP和SQL数据库（使用JDBC）的模块一起运送。它可以用来测试静止资料库或者活动资料库中的服务器的运行情况，可以用来模拟对服务器或者网络系统加以重负荷以测试它的抵抗力，或者用来分析不同负荷类型下的所有运行情况。它也提供了一个可替换的界面用来定制数据显示，测试同步及测试的创建和执行。

使用步骤：

此外，如果是在阿里云上部署服务，阿里云配套的PTS在测试计划管理和测试执行以及测试结果报告上都是非常优良的。

测试执行

测试开始执行后首选需要做的一个事情是验证下测试环境，原因比较简单——由于测试环境本身复杂性比较高，未经验证直接进行性能测试很难保证环境本身是不误的。环境验证的原则是先验证少量事务，再进行小压力的确认，最后确保环境没问题后再开始后面的按照测试计划进行测试。

接下来顺理成章的是执行测试并记录结果。这个阶段除了按照计划记录响应结果和机器指标外，服务端的日志也需要关注，至少在每个场景结束时确认下是否有错误日志。

一般服务系统的响应随虚拟用户数（VU）的增长变化如下图所示，其中0～a之间是性能表现良好的区域，一般线上性能表现的期望预期在这段范围内，所以常规的性能测试在这段范围内进行即可。a~b区间随着并发数提升TPS升高已经处于非线性区域，但对用户来说请求延迟并不是十分明显，这段区间作为负载测试区间。对应线上来说这块儿区域很少达到，在极少数高峰达到这段区域时系统尚能正常运行。b~d区域请求延迟已经明显升高，甚至TPS也开始下降，这段区间是压力测试的区间，仅测试系统崩溃点、极限吞吐等情况下具有实际意义。在实际测试中要根据响应状况及时调整并发数量以按照最初设计的目标进行。

报告整理与问题分析

测试过程按照预期和实际的表现执行结束后，系统的性能状况数据已经基本上拿到。对于满足预期的性能测试到此只要按照场景以及并发状况整理出指标结果便可完成本次任务。但对于不能满足预期的需要投入更多的精力进行分析。对于简单包含很少模块的系统进行瓶颈相对比较简单，通过临时添加性能日志便可定位出问题所在。但对于复杂系统时该如何呢，例如下面这个系统当出现性能问题时该如何定位呢？有几个思路可以供大家参考：

*按照标准添加规范的性能日志，通过性能日志可以将问题定位某个服务便可降低一个个查找的成本。

*通过trace技术查找调用链条耗时较长的部分，进而分析问题所在。

*如果以上两个都没有可以考虑将复杂系统拆分成小的子系统进行验证测试，通过讹化与排除确定问题所在。

性能测试还有非常多的内容值得我们深入探讨，今天我们从流程上先讨论这么多，更多深入有意思的事情留待我们一一深入探索。