全部产品
存储与CDN 数据库 安全 应用服务 数加·人工智能 数加·大数据基础服务 互联网中间件 视频服务 开发者工具 解决方案 物联网
性能测试 PTS

某移动APP性能优化

更新时间:2017-06-07 13:26:11

访问性能测试控制台

  移动APP项目实施案例分析及调优

1 背景

  随着客户业务发展,目前系统架构已不能满足业务发展需要,因此急需将服务器托管到阿里云上,并进行扩容;迁移到阿里云上以后,系统资源消耗是否比目前线上环境结果要好。因此在上线前需要进行性能测试,测试是否满足各项性能指标。

2 测试目标

  本次测试目标如下:

  • 容量测试:核心业务(核心业务1+核心业务2)+非核心业务基线(非核心业务1+非核心业务2+非核心业务3+非核心业务4+非核心业务5+非核心业务6)混合交易容量
  • 稳定性测试:混合交易稳定性
  • 突变测试:非核心业务突变3倍,对核心业务的影响
  • 对比测试:和线上同等压力下,线上和线下资源消耗和响应时间对比。
  • 恢复性测试:模拟网络攻击

3 架构

  系统架构主要有如下服务器:

  • HTTP服务器:核心业务1和核心业务2业务
  • TCP服务器:核心业务使用人员终端心跳业务
  • MongoDB服务器:非结构化数据库存储
  • Redis服务器:信息推送
  • MySQL服务器:结构化数据库存储

4 测试指标

  • 容量测试:核心业务1 TPS>=600笔/秒,核心业务2 TPS>=1200笔/秒
  • 稳定性测试:至少在核心业务1 TPS等于300笔/秒和核心业务2 TPS等于600笔/秒能稳定运行8小时
  • 突变测试:非核心业务突变3倍,基本对核心业务无影响
  • 线上线下资源消耗对比测试:在跟线上核心业务1 TPS等于150笔/秒和核心业务2 TPS等于120笔/秒同等压力下,测试环境的MonogoDB和Redis CPU Load小于0.5%,磁盘利用率小于0.1%
  • 线上线下存储访问时间对比测试:在核心业务1 TPS等于200笔/秒和核心业务2 TPS等于400笔/秒的情况下,应用观察到的存储访问平均耗时不超过4ms,最大耗时不超过100ms。
  • 恢复性测试:系统能恢复,TPS无变化

5 业务模型

5.1 分析

  通过生产上高峰业务量分析得出,核心业务1和核心业务2除了双12外,比例占比1:1.5左右,通过系统整个趋势观察,发现核心业务2业务量有明显增长趋势,因此核心业务1和核心业务2的占比为1:2。高峰时候核心业务总的TPS只有50~200笔/秒。
  核心业务量:

  非核心业务量:
  非核心业务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 模型

5.2.1 模型1

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

5.2.2 模型2

  此模型用于突变测试。

5.2.3 模型3

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

5.2.4 模型4

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

6 脚本设计

  经过调研,发送后台的业务均是URL+自定义Body方式,因此在性能测试里面,新增一个脚本,上传参数化文件,定义事务,设置连接和Body就行了,注意尽可能多的进行参数化。

7 测试结果

7.1 容量测试

7.1.1 测试场景

  按照模型1,设置用户数比例和步调时间(保持业务占比,不偏模型),运行20分钟,进行负载测试。

7.1.2 测试结果及分析

  • 第一轮测试
      按照核心业务1 1000笔/秒和核心业务2 2000笔/秒目标发起压力,发现不能达到目标,TPS曲线不稳定,运行到1分钟的时候,下降非常厉害,抖动也非常厉害,通过监控,发现FULL GC非常频繁,达到1秒1次,经过与架构师沟通,这是由于实现机制导致的,核心业务1的机制是将内容放到队列里面,队列长度是2147483647,后台只有64个线程(不能修改)在消化,消费者(消化)处理速度的比生产者(核心业务1)慢,导致队列长度越来越大,内存很快被消化完了,导致FULL GC频繁,这属于架构问题,不能进行修改。

  核心业务2:

  • 第二轮测试
      按照核心业务1 600笔/秒和核心业务2 1200笔/秒发起压力,运行20分钟,TPS基本保持稳定,通过监控发现,order应用连接MongoDB连接数报已满的异常错误、logserver IO过高、MongoDB locked DB值高于75%。   按照核心业务1 800笔/秒和核心业务2 1600笔/秒目标发起压力,不能达到此目标,TPS曲线非常不稳定。

  • 第三轮测试
      mongoDB 只有表锁没有行锁,导致locked值非常高,这个是产品问题,没办法进行调优。
      将order应用MongoDB连接数从250调到1000;logserver 磁盘换成效率更高SSD磁盘;重新按照核心业务1 800笔/秒和核心业务2 1600笔/秒目标发起压力,运行20分钟,TPS曲线基本稳定。

  核心业务1:

  核心业务2:

7.1.3 测试结论

  系统的容量为核心业务1 800笔/秒和核心业务2 1600笔/秒,满足核心业务1 600笔/秒和核心业务2 1200笔/秒目标要求。

7.2 线上线下资源消耗对比测试

7.2.1 测试场景

  按照模型3发起压力,在核心业务1 150TPS和核心业务2 120TPS压力情况下,运行20分钟,资源消耗对比。

7.2.2 测试结果及分析

  MongoDB 和 Redis CPU Load均小于0.5, CPU 利用率均小于10%,磁盘利用率均小于0.1%, 这些指标结果比线上资源消耗结果略好。

7.2.3 测试结论

  在跟线上同等压力的情况下,阿里云环境各项指标结果略好于目前线上环境资源消耗。

7.3 线上线下存储访问时间对比测试

7.3.1 测试场景

  按照模型4发起压力,在核心业务1 200笔/秒和核心业务2 400笔/秒的压力下,运行20分钟,观察存储访问的时间。

7.3.2 测试结果及分析

  在xflush上面观察到的存储耗时值小于3ms,最大值不超过100ms

7.3.3 测试结论

  满足目标平均耗时不超过4ms,最大耗时不超过100ms的需求。

7.4 突变测试

7.4.1 测试场景

  按照模型2,在核心业务1 TPS 400笔/秒和核心业务2 TPS 800笔/秒的情况下,平稳运行5分钟后,将非核心业务按照基线的3倍进行突变,运行5分钟,观察核心业务TPS曲线的变化,然后将非核心业务恢复到基线,观察核心业务TPS曲线的变化。

7.4.2 测试结果及分析

  核心业务1:

  核心业务2:

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

7.4.3 测试结论

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

7.5 恢复性测试

7.5.1 测试场景

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

7.5.2 测试结果及分析

  核心业务1:

  核心业务2:

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

7.5.3 测试结论

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

7.6 稳定性测试

7.6.1 测试场景

  按照模型1和最大容量的80%左右发起压力(核心业务1:600笔/秒和核心业务2:1200笔/秒),运行8小时,观察系统是否能稳定运行。

7.6.2 测试结果及分析

  核心业务1:

  核心业务2:

  运行到35分钟后,核心业务1和核心业务2 TPS开始有轻微大幅度波动,运行到45分钟后,核心业务1和核心业务2 TPS开始大幅度波动,比较频繁,并且不能恢复到初始水平(过一段时间,TPS逐渐在下降),经过分析发现是FULL GC导致,详见7.1.2测试结果及分析。   因此将压力降为一半(核心业务1:300笔/秒,核心业务2:600笔/秒),重新运行稳定性测试。

  核心业务1:

  核心业务2:

  系统在核心业务1 300笔/秒和核心业务2 600笔/秒的压力下,基本能稳定运行8小时,但随着时间推移,Full GC次数越来越多,长时间运行下去将会导致系统处理能力大幅度下降(详见7.1.2测试结果及分析)

7.6.3 测试结论

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

8 风险及建议

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

访问性能测试控制台

本文导读目录