项目实施案例分析及调优.docx

项目实施案例分析及调优.docx

《项目实施案例分析及调优.docx》由会员分享，可在线阅读，更多相关《项目实施案例分析及调优.docx（19页珍藏版）》请在冰豆网上搜索。

项目实施案例分析及调优

项目实施案例分析及调优

移动APP

文档编号：

文档名称：

编写：

审核：

批准：

批准日期：

PTS产品中心

文件修改记录

修改日期

版本号

修改描述

作者

1背景1

2测试目标1

3架构1

4测试指标2

5业务模型2

5.1分析2

5.2模型4

5.2.1模型14

5.2.2模型24

5.2.3模型35

5.2.4模型45

6脚本设计6

7测试结果6

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：

00

核心业务1

143323

0.245201125

2349

0.242741

3425

0.430385

57.0833333

核心业务2

245052

0.419242034

4084

0.422032

4533

0.569615

75.55

合计

388375

6433

7958

时间点

业务

合计

占比

平均

占比

最大值

占比

2015/01/0607：

00~08：

00

核心业务1

126989

0.217256446

2116

0.218663

3123

0.360499

52.05

核心业务2

257128

0.439902004

4215

0.435569

5540

0.639501

92.3333333

合计

384117

6331

8663

时间点

业务

合计

占比

平均

占比

最大值

占比

2014/11/1117：

00~18：

00

核心业务1

81702

0.13977814

1361

0.140643

1632

0.400294

27.2

核心业务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

编号

业务类型

业务

占比

备注

1

核心业务

核心业务1

33.3%

采用梯度施压测试，测出容量

2

核心业务2

66.7%

3

非核心业务

非核心业务1

16.4%

非核心基线，总的TPS为2433笔/秒，按照占比进行分配

4

非核心业务2

20.5%

5

非核心业务3

34.2%

6

非核心业务4

8.6%

7

非核心业务5

12.3%

8

非核心业务6

8%

此模型用于容量测试、稳定性测试和恢复性测试。

模型2

编号

业务类型

业务

占比

备注

1

核心业务

核心业务1

33.3%

按照测试出来的容量的50%压力运行

2

核心业务2

66.7%

3

非核心业务

非核心业务1

16.4%

非核心基线突变3倍，总的TPS为7299笔/秒，按照占比进行分配

4

非核心业务2

20.5%

5

非核心业务3

34.2%

6

非核心业务4

8.6%

7

非核心业务5

12.3%

8

非核心业务6

8%

此模型用于突变测试。

模型3

编号

业务类型

业务

占比

备注

1

核心业务

核心业务1

55.5%

按照核心业务1150TPS和核心业务2120TPS

情况，资源消耗对比

2

核心业务2

44.5%

3

非核心业务

非核心业务1

16.4%

非核心基线，总的TPS为2433笔/秒，按照占比进行分配

4

非核心业务2

20.5%

5

非核心业务3

34.2%

6

非核心业务4

8.6%

7

非核心业务5

12.3%

8

非核心业务6

8%

此模型用于线上线下资源消耗对比测试

模型4

编号

业务类型

业务

占比

备注

1

核心业务

核心业务1

33.3%

总的TPS为600笔/秒，方法耗时

2

核心业务2

66.7%

3

非核心业务

非核心业务1

16.4%

非核心基线，总的TPS为2433笔/秒，按照占比进行分配

4

非核心业务2

20.5%

5

非核心业务3

34.2%

6

非核心业务4

8.6%

7

非核心业务5

12.3%

8

非核心业务6

8%

此模型用于线上线下存储访问时间对比测试

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曲线的变化。

测试结果及分析

核心业务1：

核心业务2：

从图中可以看出，当非核心业务突变3倍以后，对核心业务1和核心业务2有轻微的影响（核心业务1和核心业务2TPS下降），但马上能恢复，突变的整个过程对核心业务基本无影响。

测试结论

非核心业务突变３倍对核心业务基本无影响，满足目标要求。

7.5恢复性测试

测试场景

按照模型１，在核心业务1800笔/秒和核心业务21600笔/秒的压力下，平稳运行５分钟后，断开所有mysql服务网络5秒，观察核心业务TPS曲线变化，然后恢复mysql网络，观察核心业务TPS曲线变化，接着断开所有MongoDB服务网络5秒，观察核心业务TPS曲线变化，然后恢复所有MongoDB服务网络，观察核心业务TPS曲线变化。

测试结果及分析

核心业务1：

核心业务2：

从图中可以看出，断开MySQL和MongoDB网络5秒的瞬间，核心业务1和核心业务2的TPS有轻微的下降，随后能恢复到正常水平，因此对核心业务基本没有影响。

测试结论

模拟网络攻击，对核心业务基本没有影响，满足目标要求。

7.6稳定性测试

测试场景

按照模型1和最大容量的80%左右发起压力（核心业务1:

600笔/秒和核心业务2：

1200笔/秒），运行8小时，观察系统是否能稳定运行。

测试结果及分析

核心业务1：

核心业务2：

运行到35分钟后，核心业务1和核心业务2TPS开始有轻微大幅度波动，运行到45分钟后，核心业务1和核心业务2TPS开始大幅度波动，比较频繁，并且不能恢复到初始水平（过一段时间，TPS逐渐在下降），经过分析发现是FULLGC导致，详见7.1.2测试结果及分析。

因此将压力降为一半（核心业务1：

300笔/秒，核心业务2：

600笔/秒），重新运行稳定性测试。

核心业务1：

核心业务2：

系统在核心业务1300笔/秒和核心业务2600笔/秒的压力下，基本能稳定运行8小时，但随着时间推移，FullGC次数越来越多，长时间运行下去将会导致系统处理能力大幅度下降（详见7.1.2测试结果及分析）

测试结论

在核心业务1300笔/秒和核心业务2600笔/秒的压力下，系统基本能稳定运行8小时，满足目标要求。

8风险及建议

经过多次分析、调优及测试，基本能满足各业务场景的目标要求，但系统处理能力不能再继续上升的瓶颈主要体现在系统架构上，因此随着未来业务量猛增，超过系统处理能力的时候，将会产生处理能力急需下降、客户体现差甚至宕机的风险，建议针对系统架构进行修改，并进行架构类性能测试，满足日益增长的业务需要。