项目实施案例分析及调优Word文档格式.docx
《项目实施案例分析及调优Word文档格式.docx》由会员分享，可在线阅读，更多相关《项目实施案例分析及调优Word文档格式.docx（19页珍藏版）》请在冰豆网上搜索。
7.1容量测试6
7.1.1测试场景6
7.1.2测试结果及分析6
7.1.3测试结论9
7.2线上线下资源消耗对比测试9
7.2.1测试场景9
7.2.2测试结果及分析9
7.2.3测试结论10
7.3线上线下存储访问时间对比测试10
7.3.1测试场景10
7.3.2测试结果及分析10
7.3.3测试结论10
7.4突变测试11
7.4.1测试场景11
7.4.2测试结果及分析11
7.4.3测试结论12
7.5恢复性测试12
7.5.1测试场景12
7.5.2测试结果及分析13
7.5.3测试结论14
7.6稳定性测试14
7.6.1测试场景14
7.6.2测试结果及分析14
7.6.3测试结论17
8风险及建议17
1背景
随着客户业务发展，目前系统架构已不能满足业务发展需要，因此急需将服务器托管到阿里云上，并进行扩容；
迁移到阿里云上以后，系统资源消耗是否比目前线上环境结果要好。
因此在上线前需要进行性能测试，测试是否满足各项性能指标。
2测试目标
本次测试目标如下：
Ø
容量测试：
核心业务（核心业务1+核心业务2）+非核心业务基线（非核心业务1+非核心业务2+非核心业务3+非核心业务4+非核心业务5+非核心业务6）混合交易容量
稳定性测试：
混合交易稳定性
突变测试：
非核心业务突变3倍，对核心业务的影响
对比测试：
和线上同等压力下，线上和线下资源消耗和响应时间对比。
恢复性测试：
模拟网络攻击
3架构
系统架构主要有如下服务器：
HTTP服务器：
核心业务1和核心业务2业务
TCP服务器：
核心业务使用人员终端心跳业务
MongoDB服务器：
非结构化数据库存储
Redis服务器：
信息推送
MySQL服务器：
结构化数据库存储
4测试指标
核心业务1TPS>
=600笔/秒,核心业务2TPS>
=1200笔/秒
至少在核心业务1TPS等于300笔/秒和核心业务2TPS等于600笔/秒能稳定运行8小时
非核心业务突变3倍，基本对核心业务无影响
线上线下资源消耗对比测试：
在跟线上核心业务1TPS等于150笔/秒和核心业务2TPS等于120笔/秒同等压力下，测试环境的MonogoDB和RedisCPULoad小于0.5%,磁盘利用率小于0.1%
线上线下存储访问时间对比测试：
在核心业务1TPS等于200笔/秒和核心业务2TPS等于400笔/秒的情况下，应用观察到的存储访问平均耗时不超过4ms，最大耗时不超过100ms。
系统能恢复，TPS无变化
5业务模型
5.1分析
通过生产上高峰业务量分析得出，核心业务1和核心业务2除了双12外，比例占比1：
1.5左右，通过系统整个趋势观察，发现核心业务2业务量有明显增长趋势，因此核心业务1和核心业务2的占比为1：
2。
高峰时候核心业务总的TPS只有50~200笔／秒。
核心业务量：
时间点
业务
合计
占比
平均
最大值
最大值TPS
2014/12/1217：
00~18：
00
核心业务1
351348
0.601096299
5855
0.605043
6403
0.604513
106.716667
核心业务2
233164
0.398903701
3822
0.394957
4189
0.395487
69.8166667
584512
9677
10592
2015/01/0407：
00~08：
143323
0.245201125
2349
0.242741
3425
0.430385
57.0833333
245052
0.419242034
4084
0.422032
4533
0.569615
75.55
388375
6433
7958
2015/01/0607：
126989
0.217256446
2116
0.218663
3123
0.360499
52.05
257128
0.439902004
4215
0.435569
5540
0.639501
92.3333333
384117
6331
8663
2014/11/1117：
81702
0.13977814
1361
0.140643
1632
0.400294
27.2
111120
0.190107303
1852
0.191382
2445
0.599706
40.75
192822
3213
4077
非核心业务量：
非核心业务1+非核心业务2+非核心业务3+非核心业务4+非核心业务5+非核心业务6
编号
TPS
1
非核心业务1
400
16.4%
2
非核心业务2
500
20.5%
3
非核心业务3
833
34.2%
4
非核心业务4
210
8.6%
5
非核心业务5
300
12.3%
6
非核心业务6
190
8%
2433
100%
5.2模型
模型1
业务类型
备注
核心业务
33.3%
采用梯度施压测试，测出容量
66.7%
非核心业务
非核心基线，总的TPS为2433笔/秒，按照占比进行分配
7
8
此模型用于容量测试、稳定性测试和恢复性测试。
模型2
按照测试出来的容量的50%压力运行
非核心基线突变3倍，总的TPS为7299笔/秒，按照占比进行分配
此模型用于突变测试。
模型3
55.5%
按照核心业务1150TPS和核心业务2120TPS
情况，资源消耗对比
44.5%
此模型用于线上线下资源消耗对比测试
模型4
总的TPS为600笔/秒，方法耗时
此模型用于线上线下存储访问时间对比测试
6脚本设计
经过调研，发送后台的业务均是URL+自定义Body方式，因此在PTS里面，新增一个脚本，上传参数化文件，定义事务，设置连接和Body就行了，注意尽可能多的进行参数化。
7测试结果
7.1容量测试
测试场景
按照模型１，设置用户数比例和步调时间（保持业务占比，不偏模型），运行20分钟，进行负载测试。
测试结果及分析
第一轮测试
按照核心业务11000笔/秒和核心业务22000笔/秒目标发起压力，发现不能达到目标，TPS曲线不稳定，运行到１分钟的时候，下降非常厉害，抖动也非常厉害，通过监控，发现FULLGC非常频繁，达到１秒１次，经过与架构师沟通，这是由于实现机制导致的，核心业务1的机制是将内容放到队列里面，队列长度是2147483647,后台只有32个线程（不能修改）在消化，消费者（消化）处理速度的比生产者（核心业务1）慢，导致队列长度越来越大，内存很快被消化完了，导致FULLGC频繁，这属于架构问题，不能进行修改。
核心业务2：
第二轮测试
按照核心业务1600笔/秒和核心业务21200笔/秒发起压力，运行20分钟，TPS基本保持稳定，通过监控发现，order应用连接MongoDB连接数报已满的异常错误、logserverIO过高、MongoDBlockedDB值高于75%。
按照核心业务1800笔/秒和核心业务21600笔/秒目标发起压力，不能达到此目标，TPS曲线非常不稳定。
第三轮测试
mongoDB只有表锁没有行锁，导致locked值非常高，这个是产品问题，没办法进行调优。
将order应用MongoDB连接数从250调到1000;
logserver 磁盘换成效率更高SSD磁盘；
重新按照核心业务1800笔/秒和核心业务21600笔/秒目标发起压力，运行20分钟，TPS曲线基本稳定。
核心业务1：
核心业务2：
测试结论
系统的容量为核心业务1800笔/秒和核心业务21600笔/秒，满足核心业务1600笔/秒和核心业务21200笔/秒目标要求。
7.2线上线下资源消耗对比测试
按照模型3发起压力，在核心业务1150TPS和核心业务2120TPS压力情况下，运行20分钟，资源消耗对比。
MongoDB和RedisCPULoad均小于0.5,CPU利用率均小于10%,磁盘利用率均小于0.1%, 这些指标结果比线上资源消耗结果略好。
在跟线上同等压力的情况下，阿里云环境各项指标结果略好于目前线上环境资源消耗。
7.3线上线下存储访问时间对比测试
按照模型４发起压力，在核心业务1200笔/秒和核心业务2400笔/秒的压力下，运行20分钟，观察存储访问的时间。
在xflush上面观察到的存储耗时值小于3ms，最大值不超过100ms
满足目标平均耗时不超过4ms，最大耗时不超过100ms的需求。
7.4突变测试
按照模型２，在核心业务1TPS400笔/秒和核心业务2TPS800笔/秒的情况下，平稳运行５分钟后，将非核心业务按照基线的３倍进行突变，运行５分钟，观察核心业务TPS曲线的变化，然后将非核心业务恢复到基线，观察核心业务TPS曲线的变化。
从图中可以看出，当非核心业务突变3倍以后，对核心业务1和核心业务2有轻微的影响（核心业务1和核心业务2TPS下降），但马上能恢复，突变的整个过程对核心业务基本无影响。
非核心业务突变３倍对核心业务基本无影响，满足目标要求。
7.5恢复性测试
按照模型１，在核心业务1800笔/秒和核心业务21600笔/秒的压力下，平稳运行５分钟后，断开所有mysql服务网络5秒，观察核心业务TPS曲线变化，然后恢复mysql网络，观察核心业务TPS曲线变化，接着断开所有MongoDB服务网络5秒，观察核心业务TPS曲线变化，然后恢复所有MongoDB服务网络，观察核心业务TPS曲线变化。
从图中可以看出，断开MySQL和MongoDB网络5秒的瞬间，核心业务1和核心业务2的TPS有轻微的下降，随后能恢复到正常水平，因此对核心业务基本没有影响。
模拟网络攻击，对核心业务基本没有影响，满足目标要求。
7.6稳定性测试
按照模型1和最大容量的80%左右发起压力（核心业务1:
600笔/秒和核心业务2：
1200笔/秒），运行8小时，观察系统是否能稳定运行。
运行到35分钟后，核心业务1和核心业务2TPS开始有轻微大幅度波动，运行到45分钟后，核心业务1和核心业务2TPS开始大幅度波动，比较频繁，并且不能恢复到初始水平（过一段时间，TPS逐渐在下降），经过分析发现是FULLGC导致，详见7.1.2测试结果及分析。
因此将压力降为一半（核心业务1：
300笔/秒，核心业务2：
600笔/秒），重新运行稳定性测试。
系统在核心业务1300笔/秒和核心业务2600笔/秒的压力下，基本能稳定运行8小时，但随着时间推移，FullGC次数越来越多，长时间运行下去将会导致系统处理能力大幅度下降（详见7.1.2测试结果及分析）
在核心业务1300笔/秒和核心业务2600笔/秒的压力下，系统基本能稳定运行8小时，满足目标要求。
8风险及建议
经过多次分析、调优及测试，基本能满足各业务场景的目标要求，但系统处理能力不能再继续上升的瓶颈主要体现在系统架构上，因此随着未来业务量猛增，超过系统处理能力的时候，将会产生处理能力急需下降、客户体现差甚至宕机的风险，建议针对系统架构进行修改，并进行架构类性能测试，满足日益增长的业务需要。
升级会员 