第三章 压测调优与技术演练

系统迁移上云之后，如何评估系统稳定性是我们要面临的第一个问题。本章主要讨论如何使用压力测试的方法，通过测量量化的指标来评估系统整体性能，并在压测过程中进行系统调优，以及如何使用技术演练的方法，通过具体实践的形式评估系统整体稳定性，以及这两种方法在北京冬奥保障上的应用。

3.1 云上大型赛事压测调优

3.1.1 压力测试基本概念

传统的业务系统并非生来在云上设计、云上搭建，也许我们非常了解系统的架构，清楚每个模块的规格和指标，但是系统整体在云上所能承受的性能量化级别是模糊的。此时就需要一种方法去评估系统整体性能及稳定性，这就是压力测试。

压力测试可以帮助我们量化理解该系统架构是否可承载当前至未来一段时间的业务量，也可以帮助我们发现系统瓶颈、系统可能存在的缺陷。压力测试是任何一个高可用高并发系统在上线之前必须经历的过程。

以下量化指标常被用来评估压力测试效果：

并发数：在同一时刻，同时操作同一个功能点的客户或客户端的数量。也可以理解为同时在线的用户数。

QPS(Query Per Second)：或者叫RPS(Request Per Second)，是最重要的通用指标，指系统每秒能处理的请求个数，或指客户端所发起的每秒请求量。

TPS(Transaction Per Second)：指系统每秒能处理的事务个数。在单一功能模块场景下，QPS = TPS * 每个事务所包含的请求数。假设一个事务只包含一个请求，那么 TPS = QPS。

成功率：在一定量级的QPS或TPS下，系统能成功处理的比例。在达到系统瓶颈时，成功率会极速恶化。

RT(Response1Time)：响应时间，是指用户在请求某个操作之后到获得结果之前需要等待的时间量。一般情况下这是客户端侧的参数，因此包括网络请求以及网络响应返回时间。

吞吐量：反映处理能力总量的指标，在给定的时间内处理的事务量或请求量。CPU资源利用率、内存利用率、I/O、内核参数(信号量、打开文件数)等：一些通用资源指标，不再赘述。

通常来说，一个优质的系统可以用较短的响应时间，以较高成功率处理高并发数的QPS请求，同时不会触发资源指标的性能瓶颈。而压测指标的侧重点选取则需要业务方基于业务层面的考量提供明确的压测目标。例如，在北京冬奥通APP压测过程中，确定了压测目标就是系统需要满足xW日活(DAU，Daily Active User，日活跃用户数量)，单接口成功率在99.99%以上，单接口RT在3s以内。作为云服务商，我们就可以根据此目标进一步拆解指标，完成压测。与这些指标相伴的是有关压力测试的一些术语，总结如下：

事务：是作为单个逻辑工作单元执行的一系列任务，如完成一项查询，完成一次数据传输等。一个事务可能包含多次请求。在一个事务只有一次请求的情况下，TPS = QPS。

压测机：也叫施压机，即模拟用户发起请求的机器。

单接口压测：针对具体的某个接口实施的压力测试。

全链路压测：以全链路业务模型为基础，多个接口串行实施的压力测试。

数据清理：压测过程中如果有存储操作，则可能会伴随脏数据，压测结束时要对脏数据清理掉。

功能回归：如果系统有针对压测场景进行特定的调整或更改，压测及数据清理完成后，需要进行功能回归。