51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 1137|回复: 2
打印 上一主题 下一主题

App后台性能测试项目实战

[复制链接]
  • TA的每日心情
    无聊
    2 小时前
  • 签到天数: 933 天

    连续签到: 5 天

    [LV.10]测试总司令

    跳转到指定楼层
    1#
    发表于 2022-5-7 11:35:03 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
     背景
      app收到留学push/课堂/资讯,用户点击push消息,进入app,应用加载很慢,容易出现应用假死、app崩溃或提示网络异常等信息;
      给用户体验十分不友好,监控阿里云资源tcp连接数飙高,cpu打满,自愈能力低<系统恢复能力>!
      分析
      push频率过高(这本身没有问题),从而导致收到push的用户过多,如果按10000的push到达,20%的用户同时点击,那么将造成大于等于200的用户并发量;从服务器看资源:cpu、内存、磁盘I/O一切显示正常,但是业务处理存在[url=]漏洞[/url],即离线app收到推送,打开push时,接口请求过多,一度达到30+接口,又或者可能出现服务器出现短暂网络波动,即带宽过大(大于设定值5Mbit/s),服务器自动恢复,影响范围约2min甚至更久,同时监控阿里云tcp连接数在短暂时间里达到4-6k的连接数;超出平均水平一大截<需要压测得出一个极限值>!
      小知识:理论1个tcp连接数对应1个http请求,1个push进入app,触发了3个或多个http请求<http1.1>,但是http2.0是支持并行请求tcp连接,那么1个用户请求的多个http请求创建的也是1个tcp连接,http1.1默认带connection参数,保持持久连接,但是该版本不能并行请求,出现的是多对多的关系,然后nginx可以配置http的协议版本?
      结果
      大致可以判断出,前面用户批量请求服务器,创建tcp连接过多,用户持续继续访问,那么tcp连接不能及时释放<处理更多htttp请求>,那么造成服务器tcp连接数过高,app没有接收到后端响应故而服务器响应出现请求超时!
      这时候需要性能测试,得出系统、应用程序瓶颈进行调优!!!
      准备性能测试环境:包括用户(业务)数据、接口信息、开发测试脚本等;
      设计性能测试用例:
      前提是了解业务流程,建立业务模型,即有可能出现性能问题的点,那么在开发脚本时也会对此进行单接口、组合场景的设计。
      如背景现象描述,用户收到push,从此进入app应用请求其他资源;
      那么需要获取这几个请求的接口,作为一个整体事务请求,业务分析,iOS离线推送将每个tab首页都加载了,请求接口过多,需要拆分添加子事务进行监控!
      即推送app,发起push,点击push,整体作为一个事务请求,其中首页、上课、考试、留学等根据需求拆分子事务。
      场景设计
      假设没有缓存,先关闭redis服务,进行压测,逐步加压,例如1、10、20、50、100、200、300、500进行5分钟持续并发压测,收集性能结果!
      现象还原:
      通过不断加压并发,得出服务器所承受最大并发数,系统出现瓶颈;根据监控的结果分析,开始优化:加缓存、代码优化、sql建立索引,再重复压测,以出现现象的并发数进行压测,结果是否较调优前有优化(标准:tps、响应时间、app现象等)
      性能指标计算公式:tps=通过事务总数/运行脚本总时长;
      首页代入一个性能概念:Vuser、TPS、RT;随着用户数递增请求,响应时间随之递增、通过事务数也会增加!
      a>.随着用户数增加,持续并发一段时间,RT、TPS也会随之平稳逐步增加,即上下波动略小;正常现象,但是需要分析rt、tps是否达到预期;
      b>.随着用户数增加,持续并发一段时间,RT猝然上涨、服务器可能出现cpu被打满,应用程序无法响应。
      c>.随着用户数增加,通过事务数递增,响应时间递增<终究达不到预期>,tps上不去,表示服务器处理能力低,需要分析原因;
      收集性能测试结果:进行结果分析:
      1、tps上不去的原因:由简入繁排第一位的首先检查网络带宽--连接池<服务器>--垃圾回收机制<FGC频繁>--数据库配置<如果需要写库>--通讯机制<http版本:串行、并行、长短连接>--硬件资源<cpu、内存、磁盘I/O>--负载机资源不足--脚本设计问题<需要从场景设计方向入手>--系统架构<redis缓存命中率、穿透、过期>--并发数设置问题;解决的第一个问题就是检查宽带只有3M,流量无法进来<请求服务>,被挡在外面。

     2、正常现象是可以看到tps随着用户的递增而递增

     3、响应时间也是随着并发用户数递增而递增

     4、在脚本运行之前初始化Vuser虚拟用户,随着并发用户的递增,响应时间也随之递增,在期望响应时间对应的纵坐标用户数,即为最优并发用户数<不要看响应时间上的纵坐标标识的用户数>;

    5、单机目前负载生成的用户,无论何种压测策略,都无法将服务器压垮或者app出现无法正常响应事件;需要分布式压测。
    6、在uat环境压测,当并发用户数上去之后,服务器资源cpu暴涨,出现服务假死状态,jvm排查线程,发现是底层框架导致。



    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

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

    使用道具 举报

    该用户从未签到

    2#
    发表于 2022-6-29 10:27:42 | 只看该作者
    请教下,最近要做app的后台性能,安装了LR11,使用mobile app设置代理进行录制,app手机设置了wifi的代理后开始录制,app一直不能联网,lr这边也没录到东西。请问下大概哪里的配置没做吗,有相关详细点的资料推荐下吗,谢谢
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-4-19 11:56 , Processed in 0.070882 second(s), 23 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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