目录结构

一、用户登录并发测试-结果分析
    1. 响应时间、业务成功率、并发量
    2. APDEX性能指数
    3. 系统资源使用
    4. 数据库监控
二、用户登录业务量测试-结果分析
    1. 并发量、响应时间、业务成功率、业务量、每秒事务数
    2. 系统资源使用
    3. 数据库监控
三、随机购物并发测试-结果分析
    1. 并发量、响应时间、业务成功率、每秒事务数
    2. 系统资源使用
    3. 数据库监控
四、随机购物业务量测试-结果分析

在上文[JPT_07] 性能测试-场景执行与结果收集的基础之上，本文对ECShop系统中用户登录场景（登录并发；登录业务量）、随机购买场景（购买并发；购买业务量）执行测试后的数据结果进行简要分析。

一、用户登录并发测试-结果分析

目标值：

获取测试指标提取阶段获得的用户登录并发的性能指标数据，如下：

JMeter测试结果：

1. 响应时间、业务成功率、并发量

根据JMeter执行结果后的聚合报告、or生成的html样式测试报告结果分析，统计数据如下：

从图中初步分析：
1）响应时间：登录并发测试场景中，并发量=100时，总体请求的平均响应时间≈3s，但具体到每个步骤执行的响应时间，本次以95%采样（100个采样点中的95个）数据计，有的已经超过5s，如首页访问、跳转登录页、提交登录这些过程未达到预期目标，需要重点关注和优化
2）业务成功率：并发量=100时，业务成功率=100%（测试脚本中设置有断言，可结合检查断言效果），符合预期目标
3）并发量：线程组设置100个线程，运行过程中未出现任何异常，满足100个线程并发操作的需求

2. APDEX性能指数

Apdex：APDEX性能指数（Application Performance Index），是一个国际通用标准，Apdex是用户对应用程序性能满意度的量化值。它提供了一个统一的测量和报告用户体验的方法，把最终的用户体验和应用性能作为一个完整的指标进行统一度量

下图表示通用用户满意度区域，0表示没有满意的用户，1代表所有用户都满意。实际业务系统开发过程中，1是团队所追求的目标

对于ECShop用户登录业务，100个用户并发登录的APDEX指标如下所示。从图中分析，整体Apdex值和单个步骤的Apdex值都比较小，表示用户满意度比较低，侧面说明服务器响应速度较慢。

3. 系统资源使用

利用JMeter监控服务器资源，测试完成后的结果如下所示：洋红色表示CPU占比（×1000），大红色表示Memory占比（×1000）

从图中分析：
100线程数运行，CPU占比90%-100%，Memory占比70%-80%，服务器资源占用已经达到or超过预期上限，需要重新部署资源调度分配

同时也可以结合服务器中的top命令动态监控服务器资源变化情况：
%Cpu(s)一行中的xxx id（%idle）表示某个时刻空闲CPU的占比，值越大说明服务器的CPU占用率越低；KiB Mem一行中xxx free表示空闲内存的总量

以本次为例，某个时刻9.7 id对应90.3%的CPU占用，如果id值持续降低接近0，则CPU接近满负荷（100%占用）运行，服务器的压力必然增大；若持续满负荷运行较长时间，很可能引起用户请求的服务响应失败（如：500异常状态）

4. 数据库监控

利用Spotlight监控到服务器上MySQL数据库在执行测试过程中运行的SQL语句主要为SELECT类型，与被测登录业务对数据库的操作相符合

若mysqld所占CPU、Memory较多，则需要重点优化Mysql数据库，如：减少sql查询请求数、对于页面上常用的数据进行缓存（如：Redis），降低Mysql服务器压力

二、用户登录业务量测试-结果分析

目标值：

提取用户登录业务量测试的目标，如下：

业务量目标是2h完成5w交易量，本次作简化操作，模拟执行测试10min的场景[50000/(2*3600) =6.94/s=4164/10min]，即登录业务量的目标是10min完成4164次交易量

JMeter测试结果：

1. 并发量、响应时间、业务成功率、业务量、每秒事务数

从上图分析：
1）并发量：线程组设置100个线程，运行过程中未出现任何异常
2）响应时间：以95%采样点计，登录业务量场景中的每个过程的响应时间基本都在4-5s范围内，还有优化空间
3）业务成功率：100%，过程中无响应错误；因测试时间到达后部分请求立刻停止，各个步骤的请求数存在差异，故未能保证业务的完整性
4）业务量：10min完成接近1900交易量，占目标值的45.6%，未达到预期目标；若考虑去除交易过程设置的总等待时间11s，理论上交易量比实际要高一些
5）每秒事务数：Throughput中的Transactions Per Second稳定在每秒3个左右，与预期的7个/s差距还比较大

2. 系统资源使用

登录业务量场景执行过程中，服务器上的CPU占用接近100%，已经超负荷；Memory占用接近89%，也已偏离了预期目标。mysqld服务的资源占用始终居于较高排行，需要重点优化MySQL数据化。

3. 数据库监控

SQL语句中主要为SELECT执行率，符合登录场景。Spotlight监控到的CPU占用100%，系统发出警告，分配资源调度需要优化。

三、随机购物并发测试-结果分析

目标值：

获取测试指标提取阶段获得的用户登录并发的性能指标数据，如下：

JMeter测试结果：

1. 并发量、响应时间、业务成功率、每秒事务数

从上图分析：
1）并发量：线程组设置100个线程，运行过程中的步骤[订单提交返回首页]出现了2个线程执行异常，其前2个步骤[收货信息提交、订单提交]开始服务器的事务处理能力明显下降，服务响应时间也随之大幅延缓
2）响应时间：随机购买场景中的整体响应时间较大，已经偏离目标值较远，特别是步骤[商品添加、收货信息提交、提交订单]需要重点关注优化
3）业务成功率：98.85%，未达到预期的100%。一方面可能是某些操作步骤对应代码的优化还有很大空间，数据库查询和存储数据的逻辑也需要优化，另一方面可能受限于服务器资源限制的关系
4）每秒事务数：执行开始的1min大致在10/s，第2min开始下降到3/s，而后继续执行的过程中大幅下降，说明此时服务器的处理能力下降很多

2. 系统资源使用

从上图分析：
1）在测试过程中，CPU占比持续100%满负荷运行，且Waiting占比瞬时增高，服务器处理能力受阻，持续执行则很可能引起异常增多；Memory占比接近95%，也明显偏离了预期指标
2）相关联的，执行步骤[提交收货信息、提交订单]的Response Time持续走高，需要进一步分析这些步骤是否涉及操作数据库、是否需要大量缓存、是否调用第三方地址编辑控件等，以定位到具体原因，同时也需要考虑是否因此而导致CPU、Memory占用率大幅升高

3. 数据库监控

SQL语句中的主要执行SELECT，其次是INSERTS，基本符合场景执行的设计过程，但INSERTS的展示不太明显，需要进一步分析是否是监控本身设置问题，or被测对象中SQL语句设计的原因，or因服务器资源占用而致使数据提交的过程受阻引起

四、随机购物业务量测试-结果分析

目标值：

JMeter测试结果：

在设置的10min之内，100线程并未全部完成整个交易过程，如订单提交后的一些步骤明显已受阻，响应时间大幅延缓，服务器处理能力也明显减弱，正常业务难以完成，距离目标业务量很遥远，有必要优化配置、数据库优化、操作过程对应代码的优化。此时可利用二分法验证系统稳定性测试的最佳线程数，以适配服务器资源配置