性能测试

摘要：常见的性能指标有响应时间、吞吐量、并发数。

场景：（性能测试）场景是若干个基于 HTTP/HTTPS 的 URL/API 的组合。

URL/API 可能关联了数据文件表示不同用户。
不同的 URL/API 表示不同的业务含义（比如登录、加入购物车），最终组合成一个接近用户各种真实行为同时具备一定用户量级的压测模型。

常见的性能指标

在分布式中，常见指标类型

系统能力指标

响应时间：指从客户端发送一个请求开始，到客户端最后接收到服务端返回的响应所经历的总时间。由请求发送时间、网络传输时间和服务器处理时间三部分组成。反映系统快慢。
1. 平均响应时间：
  - 但是不能选用中位数（TP50）或者平均值作为最大响应时间，因为这意味着有相当多的请求会超时。
  - 中位数意味着一半的请求会超时，而平均值则是接近一半的请求会超时。
2. TP95、TP99响应时间（95线、99 线）：保证99%的请求都能被响应的最小耗时。更科学合理的指标。
  - 以TP95为例，假设有100个（并发请求的）响应时间，从小到大排序之后，第95个响应时间的值就是这组响应时间的TP95值，表示至少有95%的数字<=这个值。
  - 如果假设应用设计的最大响应时间用 TP95，有5个请求失败、将会超时处理。
吞吐量：单位时间内处理的请求数量，通常使用 QPS 等来衡量。体现系统处理能力。
1. QPS （Queries Per Second）：系统每秒完成的请求数。是衡量系统吞吐量的关键指标，基本等同于吞吐量。
  - 在没有并发存在的系统中，请求被顺序执行。此时响应时间为吞吐量的倒数。
  - 例如系统支持的吞吐量为 100 req/s，那么平均响应时间应该为 0.01s。
2. ~~HPS：系统每秒完成的HTTP响应请求数。~~
3. TPS：~~每秒事务数。~~系统每秒完成的交易数。
  - 一个事务是指一个客户机向服务器发送请求、然后服务器做出反应的过程。
  - 客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
  - 一个页面的一次访问，只会形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，就会有多个QPS。
  - 一个交易即一个场景，当场景中只有一个API请求时，TPS数值与QPS一致。
并发数：系统能同时处理的请求数。反映系统负载。
- 并发连接数：指的是客户端向服务器发起请求，并建立了TCP连接。每秒钟服务器连接的总TCP数量。
- 并发用户数：同时发送请求的用户数量。~~同时承载正常使用系统功能的用户数量。~~例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。
- 业务成功率：

资源指标

CPU 利用率：包括用户态(user)、系统态(sys)、等待态(wait)、空闲态(idle)。
- CPU 利用率要低于业界警戒值范围之内，即小于或者等于75%;
- CPU sys%小于或者等于30%, CPU wait%小于或者等于5%。CPU Load要小于CPU 核数。
内存：现代的操作系统为了最大利用内存，在内存中存放了缓存，因此内存利用率100%并不代表内存有瓶颈。
- 衡量系统内有有瓶颈主要靠SWAP（与虚拟内存交换）交换空间利用率。
- 一般情况下，SWAP交换空间利用率要低于70%，太多的交换将会引起系统性能低下。
磁盘：磁盘繁忙率(iostat -Dl：% tm_act)要低于70%。
网络：通常不应该超过设备或链路最大传输能力的80%。

稳定性

最短稳定时间：系统按照最大容量的80%或标准压力（系统的预期日常压力）情况下运行，能够稳定运行的最短时间。
- 一般来说，对于正常工作日（8小时）运行的系统，至少应该能保证系统稳定运行８小时以上。
- 对于7*24运行的系统，至少应该能够保证系统稳定运行24小时以上。
稳定运行的定义：TPS曲线稳定，没有大幅度的波动；各项资源指标没有泄露或异常情况。

可扩展性

指应用软件或操作系统以群集方式部署，增加的硬件资源与增加的处理能力之间的关系。

计算公式为：（增加性能/原始性能）/（增加资源/原始资源）*100%。

扩展能力应通过多轮测试获得扩展指标的变化趋势。扩展能力至少应该在70%以上。

可靠性

双机热备

对于将双机热备作为可靠性保障手段的系统，可衡量的指标如下：

节点切换是否成功及其消耗时间
双机切换是否有业务中断
节点回切是否成功及其耗时
双机回切是否有业务中断
节点回切过程中的数据丢失量在进行双机切换的同时，使用压力发生工具模拟实际业务发生情况，对应用保持一定的性能压力，保证测试结果符合生产实际情况。

集群

对于使用集群方式的系统，主要通过以下方式考量其集群可靠性：

集群中某个节点出现故障时，系统是否有业务中断情况出现
在集群中新增一个节点时，是否需要重启系统
当故障节点恢复后，加入集群，是否需要重启系统
当故障节点恢复后，加入集群，系统是否有业务中断情况出现
节点切换需要多长时间在验证集群可靠性的同时，需根据具体情况使用压力工具模拟实际业务发生相关情况，对应用保持一定的性能压力，确保测试结果符合生产实际情况。

备份和恢复

本指标为了验证系统的备份/恢复机制是否有效可靠，包括系统的备份和恢复、数据库的备份和恢复、应用的备份和恢复。包括以下测试内容：

备份是否成功及其消耗时间
备份是否使用脚本自动化完成
恢复是否成功及其消耗时间
恢复是否使用脚本自动化完成指标体系的运用原则
指标项的采用和考察取决于对相应系统的测试目的和测试需求。被测系统不一样，测试目的不一样，测试需求也不一样，考察的指标项也有很大差别。
部分系统涉及额外的前端用户接入能力的，需要考察用户接入并发能力指标。
对于批量处理过程的性能验证，主要考虑批量处理效率并估算批量处理时间窗口。
如测试目标涉及到系统性能容量，测试需求中应根据相关指标项的定义，明确描述性能指标需求。
测试指标获取后，需说明相关的前提条件（如在多少的业务量、系统资源情况等）。

基本原则

响应时间指标应该与吞吐量挂钩；
响应时间指标应该与成功率挂钩；
在正式加压前应该进行基准测试，作为衡量参考值；
应该包含混合多个业务场景的性能测试；

性能测试实施

常见场景：新系统上线、升级重构、容量规划、性能探测、系统稳定性

常见的测试：

基准测试：通过单用户循环调用接口，持续10分钟, 统计响应时间的平均值，和TP90、TP99，了解接口在系统无压力情况下的性能数据。
负载测试：从0开始逐步增加系统压力，直到系统吞吐量或者系统资源消耗达到预估的标准，了解系统在安全运行下的极限。
压力测试：从负载测试探测到的系统吞吐量开始继续加压，直到系统错误率超标甚至不可以用，了解系统可服务的极限。
缓存穿透：了解系统缓存不可用以下的吞吐量。
扩展性测试：扩展应用服务器数量，了解系统扩展能力。

性能测试工具

LoadRunner（HP，商业软件）：一种多用户客户端/服务器系统的自动负载/压力测试工具。
- 能支持广范的协议和技术；支持广泛的测试对象，包括各种中间件/数据库/应用服务器的性能监控，以及j2ee和.net的测试；
- 可设置灵活的负载压力测试方案，可视化的图形界面可以监控丰富的资源；报告可以导出到Word、Excel以及HTML格式。
- 三大组件：Virtual User Generator、Controller、Analysis。
Apache JMeter（开源软件）：专门为运行和服务器负载测试而设计的纯Java桌面运行程序。除了Web测试之外，已经扩展支持各种各样的测试模块，如数据库、ftp服务器、Java对象等；可用来模拟服务器或网络系统在重负载下的运行情况。
QA Load（Compuware，商业软件）：一种模拟成千上万个虚拟用户对客户端/服务器系统的负载性能测试工具。测试的对象包括Web、数据库和Telnet等；可集成多种测试和监控工具；可预测系统性能、通过重复测试寻找瓶颈问题、从控制中心管理全局负载测试、快速创建仿真的测试、验证应用的可扩展性。
SilkPerformer（Baland，商业软件）：一种企业级负载测试工具，能够模拟成千上万的用户在多协议和多种计算环境下工作。测试的对象主要是基于Web或数据库开发的电子商务应用软件等。

性能测试流程

性能测试流程主要有三个阶段，每个阶段可以细分为多个节点：

测试调研：主要包括需求调研、需求分析、制定测试计划等；
测试准备：主要包括测试方案设计、测试环境准备、测试脚本编写、测试数据准备等；
测试执行：主要包括测试场景设置、测试执行及监控、测试结果收集及分析、测试问题分析定位、调优及回归测试、测试报告编写、测试资料归档总结等。

目录