性能测试的思考（参考阿里PTS）

线上业务压测的核心要素

做到 5 个一样
要达成精准衡量业务承接能力的目标，业务压测就需要做到 5 个一样：

• 一样的线上环境

• 一样的用户规模

• 一样的业务场景

• 一样的业务量级

• 一样的流量来源

做到 5 个“一样”，让系统提前进行“模拟考”，从而达到精准衡量业务模型实际处理能力的目标，便于相应的性能提升、限流降级方案准备等配套工作。

其实这样的条件，基本上在中小型公司是难以到达的条件。

总结出业务压测的核心要素是：

• 压测环境

• 压测基础数据

• 压测流量（模型、数据）

• 流量发起、掌控

• 问题定位

那么，压测流量（模型、数据）是可以通过 线上请求的录制拉取下来,比如使用Gor录制线上请求，序列化成Json String， 持久化到redis；流量发起可以借助于Jmeter或者Gatling、Loadrunner来产生或者也可以使用使用TCPCopy直接放大线上流量（开发和运维操作）；最后问题定位一般通过监控系统观察错误和响应时间或者通过代码打点统计日志数据，当然也可以通过自建的ELK日志分析和配合Grafana来监控服务器来排查问题，如果需要方便进行端到端的全监控和问题排查可以引入APM这样的系统。

关于压测环境和压测基础数据

结合起来一起讲：

全新生产环境。如果是刚迁移到云上或者是新的机房，全链路的进行业务压力测试之后可以进行正式投产的，这种验证效果较好，因为最终就是真实的性能环境，一般可以将真实的生产环境数据进行脱敏导入，确保业务数据量（交易数据、流水、各种业务核心业务记录等）维持在半年以上，同时确保数据的关联完整性（包括跨系统的业务完整性数据），压测基于这些基础数据进行相应的核心业务的流量（登陆、购物车行为、交易行为等）构建，最后在投产前做相应的数据清理再初始化一次存量基础数据。

等比性能环境。一般是指在生产环境单独划分区域，准备等比的容量，共享接入层的性能测试环境。这种方案缺点是成本较高，优点是方案简单、风险可控，容量规划较为精准。其中需要注意的几个点是，1必须保证有共享的接入层（CDN动态加速、BGP、WAF、SLB、4层7层负载均衡等等，确保最重要的网络接入层相同，能发现问题）；2是后端的服务容量配比上至少保证是生产环境的1/4，配比越大精准度也会大幅下降，数据库建议能相同配置。最后，在基础数据的准备上和上面全新生产环境的方法一致。

生产环境。生产环境上基础数据基本分为两种方式，一种是数据库层面不需要做改造，直接基于基础表里的测试账户（相关的数据完整性也要具备）进行，压测之后将相关的测试产生的流水数据清除（清除的方式可以固化sql脚本或者落在系统上）；另一种就是压测流量单独打标（如单独定义的Header），然后业务处理过程中识别这个标并传递下去，包括异步消息和中间件，最终落到数据库的影子表或者影子库中，一般称之为全链路压测。此外，生产环境的压测尽量在业务低峰期进行从而避免影响生产的业务，无论上述哪种方式都可以通过部署单独的压测专用集群来进一步避免对生产业务的影响。

关于业务的挡板

一般生产环境的业务压测还会涉及到和第三方的交互，如短信、支付和渠道对接等等，往往需要mock掉。最后，关于方案的选择应该结合实际的情况如人力资源、机器资源、时间成本、业务复杂度、业务要求和后续的维护成本综合考虑最适合自身的方案。

理想的性能测试方案, 至少满足如下几个场景

• 可持续集成，也就是固定的服务在部署到特定的环境后可以自动使用老的数据回归性能。

• 监控平台化，可以随时调出待测服务器集群中的某台设备查看TPS/QPS和CPU 句柄数 连接数 流量 JVM的profile数据 数据库的状态数据 。

• 应用自身log统计数据的对应关系图，可以随时调出上个季度的服务器性能和当前的服务器性能做对比。

• 问题定位方便，可随时根据时间点和曲线图的拐点分析特定时间段的各类指标和应用log

性能测试方法的核心

根据不同的测试目的，性能测试可以分为多种类型，常见的有如下几类：

• 基准测试（Standard Testing）

• 负载测试（Load Testing）

• 压力测试（Stress Testing）

• 疲劳强度测试

首先说下基准测试。基准测试指的是模拟单个用户执行业务场景时，考察系统的性能指标。严格意义上来讲，基准测试并不能算作性能测试范畴，它跟功能测试并没有太大区别。差异在于，基准测试的目的更多地是关注业务功能的正确性，或者说验证测试脚本的正确性，然后，将基准测试时采集得到的系统性能指标，作为基准测试结果，为后续并发压力测试的性能分析提供参考依据。

负载测试，主要指的是模拟系统在正常负载压力场景下，考察系统的性能指标。这里说的正常负载，主要是指用户对系统能承受的最大业务负载量的期望值，即预计系统最大应该支持多大用户的并发量。通过负载测试，目的是验证系统是否能满足预期的业务压力场景。

和负载测试的概念比较接近的是压力测试。通俗地讲，压力测试是为了发现在多大并发压力下系统的性能会变得不可接受，或者出现性能拐点（崩溃）的情况。在加压策略上，压力测试会对被测系统逐步加压，在加压的过程中考察系统性能指标的走势情况，最终找出系统在出现性能拐点时的并发用户数，也就是系统支持的最大并发用户数。

最后再说下疲劳强度测试。其实疲劳强度测试的加压策略跟负载测试也很接近，都是对系统模拟出系统能承受的最大业务负载量，差异在于，疲劳强度测试更关注系统在长时间运行情况下系统性能指标的变化情况，例如，系统在运行一段时间后，是否会出现事务处理失败、响应时间增长、业务吞吐量降低、CPU/内存资源增长等问题。

通过对比可以发现，不同的性能测试类型，其本质的差异还是在加压策略上，而采用何种加压策略，就取决于我们实际的测试目的，即期望通过性能测试发现什么问题。明白了这一点，性能测试类型的差异也就不再容易混淆了。

结论要点1：性能测试手段的重点在于加压的方式和策略。

性能瓶颈定位的核心

在前面频繁地提到了性能指标，那性能指标究竟有哪些，我们在性能测试的过程中需要重点关注哪些指标项呢？

从维度上划分，性能指标主要分为两大类，分别是业务性能指标和系统资源性能指标。

业务性能指标可以直观地反映被测系统的实际性能状况，常用的指标项有：

• 并发用户数

• 事务吞吐率（TPS/RPS）

• 事务平均响应时间

• 事务成功率

而系统资源性能指标，主要是反映整个系统环境的硬件资源使用情况，常用的指标包括：

• 服务器：CPU利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘IO状态、网卡带宽使用情况等；

• 数据库：数据库连接数、数据库读写响应时长、数据库读写吞吐量等；

• 网络：网络吞吐量、网络带宽、网络缓冲池大小；

• 缓存（Redis）：静态资源缓存命中率、动态数据缓存命中率、缓存吞吐量等；

• 测试设备（压力发生器）：CPU利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘IO状态、网卡带宽使用情况等。

对于以上指标的具体含义我就不在此进行逐一说明了，大家可以自行搜索，务必需要搞清楚每个指标的概念及其意义。可能有些指标在不同的操作系统中的名称有些差异，但是基本都会有对应的指标，其代表的意义也是相通的。例如，处理器队列长度这个指标，在Windows中的指标名称是System\Processor Queue Length，而在Linux系统中则需要看load averages。

TPS模式（吞吐量模式）是一种更好的方式衡量服务端系统的能力。

TPS获取新系统：没有历史数据作参考，只能通过业务部门进行评估。旧系统：对于已经上线的系统，可以选取高峰时刻，在5分钟或10分钟内，获取系统每笔交易的业务量和总业务量，按照单位时间内完成的笔数计算出TPS，即业务笔数/单位时间（560或1060）

系统的性能由TPS决定，跟并发用户数没有多大关系。
系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。

可能对于最后一项（测试设备）有些人不大理解，监控被测系统环境的相关硬件资源使用情况不就好了么，为什么还要关注测试设备本身呢？这是因为测试设备在模拟高并发请求的过程中，设备本身也会存在较高的资源消耗，例如CPU、内存、网卡带宽吃满，磁盘IO读写频繁，处理器排队严重等；当出现这类情况后，测试设备本身就会出现瓶颈，无法产生预期的并发压力，从而我们测试得到的数据也就不具有可参考性了。此处暂不进行展开，后面我会再结合实际案例，通过图表和数据对此详细进行说明。

需要说明的是，性能指标之间通常都是有密切关联的，单纯地看某个指标往往很难定位出性能瓶颈，这需要我们对各项性能指标的含义了然于胸，然后才能在实际测试的过程中对系统性能状况综合进行分析，找出整个系统真正的瓶颈。举个简单的例子，压力测试时发现服务器端CPU利用率非常高，那这个能说明什么问题呢？是服务端应用程序的算法问题，还是服务器硬件资源配置跟不上呢？光看这一个指标并不能定位出产生问题的真正原因，而如果仅因为这一点，就决定直接去优化程序算法或者升级服务器配置，最后也很难真正地解决问题。

作者：我为峰2014
链接：https://www.jianshu.com/p/7b625f20cbb5