性能测试方法论

目录

基准的确定

性能测试的第一步就是根据当前的测试环境确定基准。不然如何判定性能的好坏？如何判定优化的方向？

所以，基准测试是非常重要的第一步。性能参数跟测试环境的方方面面都有关联，例如：物理服务器资源、网络中间件数量、客户端性能等。为了测试服务端的某一项性能，我们很可能会为此放弃其他的性能项目。所以，即便我们已经通过官方渠道掌握了一个业界水准的性能数据，也不能作为当前环境的判断依据。也就是说，性能测试的结论不应该将任何外部公开的性能指标作为基准，而是应该以自己的测试环境为准。

以测试运行在虚拟机上的 HAProxy 的性能为例，首先进行的基准测试就：

1. 在物理服务器上测试 HAProxy 的性能参数。
2. 在同一型号的物理服务器上运行虚拟机，然后在虚拟机上运行 HAProxy 并测试其性能参数。

期间逐步添加性能调优的方法，观察性能数据是否正向上升，最终数值逼近物理服务器上的性能数据。

测试模型

测试模型设计的核心在于：杜绝压力机和负载机的瓶颈，让被测对象成为唯一的性能瓶颈，由此得出被测对象的峰值数据。

• 压力机：负责打压
• 负载机：负责承受业务压力
• 测试机：被测对象，例如：HAProxy。

显然，测试机才是我们核心关注的对象，是性能优化的关键。前提是压力机和负载机没有成为你的瓶颈，只有在保证这个前提的基础上，测试所得到的数据才是最真实的数据。

解决这个问题的思路是逐步建立经验数据，以一个预估的步进逐渐扩展压力机和测试机的规模。理想的结果可以观察到性能数据会随着压力机和负载机的水平扩展而线性增长。在保持压力机和负载机的常规资源（CPU、内存）不超过 80% 的情况下，水平扩展直到性能数据到达峰值。

在达到峰值之，并不意味着不再扩展压力机和负载机，而是应该继续扩展一个合理的规模。例如：在 10 台压力机的情况下到达了峰值，那么还应该再继续扩展至 12-15 台，然后在这样的条件下摸索性能的瓶颈，对测试机进行调优。

网络性能的关键参数

延迟

延迟（Latency）是测试机对客户端请求的响应速度的度量，单位：ms（毫秒），表示响应时间，数字越小性能越好。注意，延迟是端到端的，包括：客户端的性能、服务端性能、以及网络中间件的开销。所以，在基准测试阶段应该对客户端性能、网络中间件开销等数值有一个掌握。

最大连接数

是测试机在同一时刻可以建立的最大的客户端连接数量，数字越高则测试机的容量越大越好。注意，最大连接数并不意味着全部连接的请求都是成功的，这取决于测试目标的偏向。

每秒新建连接数（CPS）

每秒新建连接数（CPS）是测试机每秒可以新建多少连接的度量，数字越高则测试机的处理能力越好。基于使用协议的不同，CPS 可以分为 L4 CPS 和 L7 CPS。

L4 CPS 测试的目的是确定最大的 TCP 连接建立速度。同样需要关注测试目标的偏向：如果只关注 TCP 层的建立速度，TCP 连接建立成功即可，那么关注的实际是 TCP 连接三次握手的过程，而且连接处于 OPEN 状态；如果关注的是 TCP 的完整链接状态，那么就包括：三次握手建立、持续和关闭的过程，而且在关闭过程中，又可以选择发送 TCP FIN 或者 RST 报文的方式。

测试 L7 CPS 时，采用 HTTP1.1 协议的 GET 请求。需要注意的是，传输的数据大小会占用测试机的系统资源，从而影响测试结果。在 RFC 3511 中没有明确应答数据的大小，所以通常可以设置为 1byte 甚至更小。

CPS 作为吞吐量的前置，两者通常是正相关的。

每秒查询数（QPS）

每秒查询数（QPS），又称吞吐量（Throughput），是测试机每秒可以处理多少请求的度量，用于衡量并发请求数。通常使用测试机在特定时间间隔内可以处理的请求数来进行判定。注意 QPS 和最大连接数并非线性关系或正向关系。所以 QPS 并不十分关注连接数。

例如：一台服务器只有 10 个客户端连接，每个客户端连接上每秒有 1W 个请求，那么要求服务端需要至少能支撑 10 * 1W = 10W QPS（每秒的吞吐量）。假设 10W QPS 是这台服务器的极限，那么反之：如果每个客户端每秒发送 1 个请求给服务端，那么 这台服务器能够支撑 10W 个客户端，10W 的并发数。

系统负载指标

监视除开被测对象之外的其他系统指标（通常是 CPU、Memory），以判定服务器是否受到资源的限制，数字越低越平稳，则性能越好。这有助于我们考虑应用程序是否有必要进行扩展，或者应该如何扩展，或者应该在什么方面集中精力。在 Linux 上有很多友好的监视工具，例如：top 等。除了关注测试机的负载之外，经常也要要求压力机和负载机处于低负载条件，以判定压力机和负载机没有成为性能瓶颈。

常规的压力测试步骤

压力测试是测试软件性能的惯用手段，常用于寻找服务器（或应用程序）每秒可以处理的最大请求数。通过向服务器发送尽可能多的请求并查看可以成功返回多少请求来完成判定。压力测试对于了解服务器的最大容量非常有用，但实际上我们不仅仅只追求最大容量，还需要观察延迟、成功率等一系列的参数项目。

1. Monitoring Resources：监视系统的各项负载指标，以备作为调整测试思路的参考。
2. Finding the Maximum Response Rate：极端打压，直到服务器的最大容量，这时被测对象应该会出现各样的请求失败。在过程中我们可以判定服务器的资源是否足够，是否会成为瓶颈。
3. Find the Maximum Practical Throughput：设定几组压力数据，在保证成功率 100% 的前提下，让被测对象成为瓶颈，并调整各项性能参数，比如：延迟、吞吐量等，

参考文档

https://www.digitalocean.com/community/tutorials/an-introduction-to-load-testing
https://www.nginx.com/blog/testing-the-performance-of-nginx-and-nginx-plus-web-servers/