51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2751|回复: 0
打印 上一主题 下一主题

[原创] 大规模分布式系统性能测试实践

[复制链接]
  • TA的每日心情
    奋斗
    2018-11-26 09:42
  • 签到天数: 11 天

    连续签到: 1 天

    [LV.3]测试连长

    跳转到指定楼层
    1#
    发表于 2018-9-7 15:52:43 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
    一、云时代的应用性能测试挑战

    二、华为云性能测试实践方案如何更加系统的开展性能测试活动
    • 被测对象分析

    • 测试场景分析建模

    • 测试需求分析

    • 工具选型与搭建

    • 测试执行

    • 性能测试分析与调优



    1.    被测对象分析(某社交类APP)

    从系统架构分析可能出现的瓶颈点,作为重点测试场景

    Feed流会频繁操作后台的Redis等服务,每次操作会产生100+次网络操作,200+次key/Value运算,因此会成为系统的主要性能瓶颈

    备注:Feed是将用户主动订阅的消息源组合在一起形成内容聚合器,帮助用户持续地获取最新的订阅源内容,在社交类应用中被广泛使用若干


    2.    测试场景分析建模

    业务特点:用户增长迅速、突发事件高流量并发

    Step1:以使用场景为主线,构建性能模型(使用角色、使用阶段等)

    Step2:分析每个操作场景的影响因子,如好友、关注数量等,建立每个场景的测试模型


    单场景一级接口测试

    单场景二级接口测试

    如需测试某个对性能的影响,可递增方式改变因子值进行测试


    按照页面权重分配压力模型,实际在生产环境比例会不断变化,因此在性能摸底过程中需要不断调整摸底

    示例:全页面混合压测模型


    3.    测试工具需求分析

    识别关键场景测试需求

    1)      HTTP协议/Rest接口  

    2)      用户登陆认证 ,模拟多用户操作

    3)      支持接口串联场景,需要上下文关联

    4)      性能暂无基线,需要支持递增模式快速摸底

    5)      各页面用户量未知,需要灵活调整混合模型配比

    6)      由于社交类应用业务增长迅速,因此需要支持按需使用,随时扩大工具的并发量

    7)      需要支持10万以上的并发

    8)      测试结果易于观察、保存

    9)      提供监控能力,便于快速定位


    4.  测试服务选型与搭建

    测试服务选项原则:功能满足、效率高(即开即用)、成本低

    云服务更适合测试高扩展性的大规模分布式系统


    5. 测试执行

    分层开展性能测试,在集成阶段确保性能测试活动可开展


    测试执行的一些典型问题

    性能是一个逐步提升的过程,测试过程中需要找到扩容的模型,从不足50的TPS提升至万级

    6.  测试结果分析

    1.1  如何从测试工具侧快速分析被测对象可能存在的问题

    ·         存在部分响应超时:

    a)       服务器繁忙,如某个服务节点CPU利用率高

    b)      网络IO超过VM/EIP带宽

    c)       等待后端微服务、数据库的超时时间设置过长

    ·         运行一段时间后全部响应超时或者检查点校验不通过:

    a)       大压力导致系统中某个微服务奔溃

    b)      后端数据库无响应

    ·         TPS未随着并发数增长而上升:

    a)       系统性能到达瓶颈,持续并发加压过程中响应时延增加(可观察响应区间统计)

    b)      可通过进一步加压是否会出现非正常响应验证

    ·         TP90响应时延较短,TP99时延高:

    a)       系统性能接近瓶颈

    b)      可通过进一步加压是否会出现非正常响应验证


    1.2  一些通用优化建议

    1)      扩容,链路中的某一应用可能出现cpu使用率较高或者连接池资源不够用(rpc、jdbc、redis连接池等)但本身对于拿到连接的请求处理又很快,这一类需要横向扩展资源。

    2)      应用逻辑优化,比如存在慢sql、 逻辑的不合理如调用db或者redis次数过多、没有做读写分离造成写库压力过大。

    3)      超时时间的合理设置,对于应用之间的rpc调用或者应用与其他基础组件之间的调用,均需要设置合理的超时时间,否则过长的等待将造成整个链路的故障。

    4)      缓存的应用,请求尽可能从前端返回,而不是每一个都要让后端应用处理后再返回,减轻后端应用及数据库压力,提高系统吞吐能力。

    5)      限流,对于超出承载能力的QPS或并发,可以进行拦截并直接返回提示页面。

    6)      降级,对于非核心链路上的应用,允许故障关闭而不影响核心链路

    7)      扩容和优化也是有限度的,在评估容量内,保障核心交易链路正常是重中之重,对于非核心功能模块考虑降级场景


    三、某互联网平台案例

    业务特点:突发事件高流量突发,如瞬间由百级用户增长到万级

    对于网络架构复杂的应用,可以通过网络架构上的分段验证,如分别从最外端的CDN入口(1)中间的ELB(2)业务层(3)分别做测试,验证网络架构上的瓶颈和影响

    应用内部的性能瓶颈如何提升定位效率?


    四、性能测试的最后一公里

    集成APM,解决性能问题定位最后一公里问题,大幅提升性能测试效率

    如:xxx并发情况下,服务A调用服务B的事务1出现问题,并直接定位至出错函数

    • 在上线和活动前期通过云性能测试服务进行压力测试,发现部分接口的响应时间比较长,会出现比对失败和响应超时,通过APM的调用链分析,发现有部分SQL语句比较耗时,针对这些SQL查询语句,建立了索引,快速定位问题并迅速解决。

    • 最终经过两轮测试优化后,官网首页访问响应超时与正常返回比提升了43.3%,预约试驾场景响应超时与正常返回比降低到0,提升了100%。

    • 性能瓶颈定位时间,从官网未使用APM时需要1周,缩短到俱乐部使用APM后的0.5天,效率提升90%


    应用拓扑

    事务监控

    调用链跟踪

    五、性能测试服务关键能力要求


    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-25 08:46 , Processed in 0.573244 second(s), 23 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表