705      微信

某移动APP性能优化__最佳实践_性能测试-阿里云

访问性能测试控制台

  移动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

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 测试场景

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

7.1.2 测试结果及分析

• 第一轮测试
    按照核心业务1 1000笔/秒和核心业务2 2000笔/秒目标发起压力，发现不能达到目标，TPS曲线不稳定，运行到１分钟的时候，下降非常厉害，抖动也非常厉害，通过监控，发现FULL GC非常频繁，达到１秒１次，经过与架构师沟通，这是由于实现机制导致的，核心业务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 测试场景

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

7.3.2 测试结果及分析

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

7.3.3 测试结论

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

7.4 突变测试

7.4.1 测试场景

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

7.4.2 测试结果及分析

  核心业务1：

  核心业务2：

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

7.4.3 测试结论

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

7.5 恢复性测试

7.5.1 测试场景

  按照模型１，在核心业务1 800笔/秒和核心业务2 1600笔/秒的压力下，平稳运行５分钟后，断开所有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 风险及建议

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

访问性能测试控制台

最后更新：2016-05-06 10:44:38

  上一篇： 大规模分布式压测__最佳实践_性能测试-阿里云

  下一篇： 录制工具使用指南__脚本录制调试指南_性能测试-阿里云