移动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 风险及建议
经过多次分析、调优及测试,基本能满足各业务场景的目标要求,但系统处理能力不能再继续上升的瓶颈主要体现在系统架构上,因此随着未来业务量猛增,超过系统处理能力的时候,将会产生处理能力急需下降、客户体现差甚至宕机的风险,建议针对系统架构进行修改,并进行架构类性能测试,满足日益增长的业务需要。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。