服务端系统性能测试

概述

很多测试人员对于性能测试实践的机会不多，所以很难获得相关的实践经验，也很难系统的总结出性能测试相关的知识。为了方便大家能快速的系统的从整体上了解性能测试，我总结了性能测试洞见 101 系列文章，今天就让我们来聊聊服务器端系统性能测试。

特点

首先，总体上来讲，服务器端系统性能测试具有以下三个特点：

• 需求比较困难

• 技术相对简单 

• 过程十分繁琐

性能需求的获取一般都是十分困难的，因为很少有人能明确地提出性能需求，要么是新系统，不知道生产环境的性能需求是多少；要么就是不懂技术，无法提出正确合理的性能需求等。对于无法获得性能需求的项目，通常只能通过压力测试后并找到系统的性能极限，反过来把实际的性能指标给客户，从而确实是不是满足客户需求。 性能测试的技术层面一般都相对简单，只要不是需要几十上百万的并发测试。业界多款开源性能测试工具都可以很容易地实现性能测试，比如 Gatling，Locust，JMeter，K6 等。 但是过程十分繁琐，其中包括环境和数据的准备，确认，重置等，各种第三方依赖服务准备或者模拟等，测试结果分析和确认等。

目标

其次，服务器端性能测试的三个主要目标：

• 验证性能

• 发现性能和功能问题

• 辅助性能调优

这三个主要目标都十分容易理解，其中只有功能问题也许并不是很多人都遇到过。比如一个购物系统里面，当结算以后需要更新商品状态成已经结算。如果存在一个 bug，就是 A 客户在某个特定的情况下结算失败了，由于并发没有控制好，同时也把正在购物的客户 B 的商品也结算失败了。

分类

最后，对于服务器端的性能测试，一般包含以下几个基本分类：

• Load Testing   - 负载测试

• Stress Testing - 压力测试

• Soak Testing   - 耐久测试

• Spike Testing  - 瞬压测试

不少人认为性能测试只是负载测试或者压力测试，但是我认为只要是专门为了验证系统性能并以发现性能问题为主要目的测试都是性能测试，所以耐久测试和瞬压测试等也是属于性能测试。

实践

难点

服务器端性能测试的三个难点分别是：验收需求的获取，测试模型的建立 ，测试环境的搭建。大部分项目中一般情况下验收需求的获取难度大于测试模型的建立，而测试模型的建立则大于测试环境的搭建。

指标

而对于性能测试的主要技术指标包括以下几点：

• QPS / RPS / TPS

• Concurrent Users / Concurrent Requests

• Response Time(min/max/mean/std/90%…)

经常大家会看到这几个词 QPS（Query Per Second） / RPS（Request Per Second） / TPS（Transaction Per Second）。它们只是针对不同的场景的时候的不同的描述，比如 QPS，主要是针对只有查询请求的系统的性能指标，而 TPS 则是表示一个具有事务的系统，其中包含数据创建，更新，查询等不同请求的系统的性能指标。 其次是 Concurrent Users 和 Concurrent Requests，它们也是性能测试必不可少的指标，也十分容易理解，就是表示并发用户数和并发请求数。理论上某一时刻的并发请求数应该小于或者等于并发用户数，不然你的性能测试模型就存在问题。 最后 Response Time 也是一个非常重要的性能指标，也十分容易理解和使用。但是其中有一个 std（标准差）的指标则不是被经常使用，但是也是十分有用的，可以用来分析服务器性能的稳定性。如果它的值越大，表示服务系统的性能越不稳定，越小则性能越稳定。

而业务指标则包含：

• 平均同时在线用户数

• 同时在线用户数

而往往我们和业务人员沟通的时候，它们很难给出上面的性能技术指标，而只能给一些业务指标，比如平均同时在线用户数和同时在线用户数。而技术人员又往往很难理解这两个指标，下面通过两个例子来说明这两个指标。

例子 1:平均同时在线用户数

假设有一个 OA 系统，该系统有 3000 个用户，平均每天大约有 400 个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为 4 小时，在一天的时间内，用户只在 8 小时内使用该系统。 平均同时在线用户数： 理论值：400*4/8 = 200 人

例子 2: 同时在线用户数

假设有一个 OA 系统，该系统有一个业务需要串行访问 6 个 API，每个 API 单次最短 Response Time 是 100ms，每个 API 的 Max RPS 是 100，每个 API 的 timeout 时间是 20s。假设平均每个用户需要访问完 6 个 API 完成一个业务需要 1 分钟。 同时能完成业务的在线用户数： 理论值：100*(60/6)=1000 人/分

性能测试步骤

虽然不同的项目的性能测试的类型和细节都有所不同，但是我通过多年的性能测试经验，总结了以下几步通用的性能测试步骤：

1. 确定性能需求（可选）

2. 准备测试环境和测试数据

3. 选择性能测试工具/平台，

4. 制定性能测试模型，编写性能测试代码

5. 运行性能测试

6. 分析测试报告，根据不同的情况重新做前面不同的步骤

7. 性能调优 | 修复问题 ，根据不同的情况重新做前面不同的步骤 其中第 1 步如果能获得性能需求则是最好的情况，如果不能，则需要完成第 6 步性能分析以后，重新做第 1 步来确定性能需求。如果在第 7 步性能调优之后，也需要重新运行性能测试和分析性能测试报告。

总结：

性能测试的一些总结

• 性能测试核心三点：网关，应用系统，数据库 我所经历的项目中，大部分性能问题都是出现在这三点上。 比如项目 1，它是一个并发十万级别的数据读取的服务系统。虽然测试环境通过优化应用系统和数据库可以支持十万并发，但是在产品环境还是出现了性能问题，最后发现是由于产品环境的网关中的防火墙导致无法支持这么高的并发。 比如项目 2，一个购物系统，在数据库数据量小的情况下，没有任何性能问题。但是当数据库中的数据量达到几百万时，系统的性能就十分差。最后发现原因是数据库表中的主键用的是 UUID，从而导致查询速度非常慢。 所以做服务系统性能测试的时候，一定要关注这三个核心点上各自的性能，而不仅仅只关注应用系统和数据库的的性能。只有这样才能在产品环境中获得一个性能合格的系统。

• 性能测试的梦想目标：核心三点都分别性能最优，并且全链路长时高压能正常运行 对于服务端系统的性能，性能测试的目标就是和开发人员一起，把核心三点的性能优化到能满足业务需求，而最理想的情况就是优化到最优。其次可以在全链路高压的时候都能正常运行，而不会崩溃。就算遇到了 DDOS，网络被堵塞的时候，系统也不应该崩溃，重启等。

• 性能提升的终极目标：核心三点都能动态的平滑的水平扩展 而对于系统的性能提升，我们期望的终极架构目标是核心三点都能动态的平滑的水平扩展。对于应用系统的动态扩展相对容易一点，但是对于网关则比较难以实现。对于数据库的性能优化，通常可以使用分表，分库，读写分离，但是这些方法都很难做到动态的平滑的水平扩张。但是最近几年分布式 NewSQL 数据库的出现，已经比较好地解决了这个难题。所以我们离性能提升的终极目标已经不远了。

• 性能保证的辅助手段：流量控制，熔断，服务降级 对于性能保证的辅助手段，流量控制是最有效的方法，主要是在网关层实施。其次熔断和服务降级是对于多服务系统来讲，可以有效地保证点单故障影响整体系统的服务和性能。

• 性能规划：通过性能测试来规划产品环境的规模，并用以支撑不同的业务需求 对于性能保证的辅助手段，流量控制是最有效的方法，主要是在网关层实施。其次熔断和服务降级是对于多服务系统来讲，可以有效地保证点单故障影响整体系统的服务和性能。    

原文