• 0
  • 0
分享
  • 时间减少90%以上!分布式系统的性能优化实战——软件测试圈
  • 曼倩诙谐 2024-03-21 11:18:38 字数 1966 阅读 259 收藏 0

  1 背景

  分布式批量系统指的是采用分布式数据库架构,主体功能由批量程序实现的系统。分布式系统批量程序的性能测试,除了和联机交易性能测试一样关注服务器资源使用率是否合理、是否存在性能异常外,在测试执行阶段需要关注是否因数据分布不均衡导致部分并发子程序执行时间过长,成为整体批量程序的“短板”,从而影响批量程序的整体时间。

  下面我主要介绍一种分布式系统批量程序性能优化的思路,并结合实际测试效果说明。

  2 分布式系统分片和批量并发规则

  被测系统数据库为分布式数据库,存储并处理某公司各个机构的业务数据,包括若干个数据库分片、500多个分片键(分布式表的一个主键字段,用来区分数据存放的分片),分片键值是由机构ID号(以下简称机构号)按照一定规则映射而来。每个分片包含若干分片键,某个分片键对应若干机构的数据。

  批量程序执行时,根据系统相关配置表中的静态配置,500多个子程序并发分别处理对应分片键下的业务数据。各个子程序处理逻辑相同,所以当某些子程序待处理的数据量相对其他子程序过多时(即该分片键下机构数据明显多于其他分片键下数据),这些耗时长的子程序会拖慢整体程序的效率。

1-1.png

图1 分片与分片键对应关系

  3 抢任务方式优化数据分布不均衡的批量程序

  3.1 由静态并发改造抢任务模式

  根据系统按分片键静态并发的特点,当批量程序子程序间处理数据分布不均衡时,部分子程序执行时间过长,成为整体批量程序的“短板”,从而影响批量的整体时间。为解决上述问题,本系统采取了“抢任务”的动态并发优化方法。

1-2.png

图2 抢任务改造前后批量程序逻辑对比

  1)将待处理表中的所有数据,按照一定的维度(如机构号+该表的某个参数值)划分成若干个任务,单个任务就是某个机构下某参数值对应的数据。

  2)在实际处理数据程序执行之前,添加一个生成任务程序,执行该程序就会在任务表中添加全部任务的记录,所有任务当前处于初始化状态。

  3)生成任务程序执行后,自动调起数据处理程序,改造后的程序不再按照静态并发,而是去查询任务表中状态为初始化且数据量大(优先级高)的任务,任务结束时,处理状态改为已完成,子程序查找下一个未处理的任务,直到任务表没有状态为初始化的任务,所有子程序成功执行完成。

  实际测试场景执行时采用1600万条数据对某批量程序(该程序处理的业务数据,各个分片键下的数据极不均衡,经分析适用于本优化方法)进行测试数据准备,按照优先级处理任务300个子程序动态并发执行,按当前维度共生成11万个任务,所有子程序均在33分钟内完成,无明显过长的子程序,总体执行时间32分21秒,系统资源和数据库资源利用率均正常。

  3.2 优化任务处理数据量

  按前述优化的生成任务维度,有个别任务处理数据量仍然很大,如果不进行进一步拆分还是存在一定“短板”,且生成的任务过多,大量任务都是小数据量任务,处理数据程序频繁抢“小任务”并更新数据的效率较低。为解决上述问题,程序进行了第二次优化。

  1)生成任务时增加限制任务处理数据量的参数,该参数作用是规定单个任务的最大数据处理数,当同一分片键维度的任务处理数据量未达到这个值时,将这几个任务合并为一个更大的任务,如果分片键发生了切换,则生成下一个任务。

  2)对于原有维度拆分出来的大任务,通过增加维度的字段,使单个维度的处理数据量降低,这样一个维度包含的数据更小,同时也参照上述参数限定任务最大数据处理数。

  上述优化主要目标即控制个别“大任务”的处理数据量,合并多数“小任务”,使任务总量变少,减少抢任务造成的时间成本,并且任务之间处理数据量更均衡。

  按上述策略优化的生成任务程序和数据处理程序,并发数不变,仍然采用同样数据进行准备并执行测试,由于生成任务的规则变化,生成的任务量由原来的10万以上降低到1000以内,生成任务时间增为2分40秒,执行数据处理程序时间降低为12分33秒,生成任务和处理数据的总执行时间比第一次优化明显提升。下表是两次优化执行性能测试执行时间对比。

1-3.png

  该批量程序按上述策略两次优化后,生产环境中处理时间由优化前的近4小时缩短到15分钟左右,时间减少90%以上,且系统资源运行平稳,无性能瓶颈。

  4 总结及展望

  通过分布式系统的性能测试实践,我们根据系统特点在批量程序性能优化方面积累了一定经验。抢任务性能优化方式解决了批量程序不同分片键处理数据量不均衡导致的执行时间过长问题,在项目测试中取得了明显的优化效果。

  未来我还将持续探索分布式系统的批量测试技术和测试方法,加强系统分析与调优能力,为提升分布式批量系统效率及可靠性继续努力。


作者:王谦    

来源:http://www.51testing.com/?action-viewnews-itemid-7800177

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 作为软件开发从业者,API 调试是必不可少的一项技能,在这方面 Postman 做的非常出色。但是在整个软件开发过程中,API 调试只是其中的一部分,还有很多事情 Postman 无法完成,或者无法高效完成,比如:API 文档定义、API Mock、API 自动化测试等等。Apifox 就是为了解决这个问题而生的。接口管理现状一、常用解决方案使用 Swagger 管理 API 文档使用 Postman 调试 API使用 MockJs 等工具 Mock API 数据使用 JMeter 做 API 自动化测试二、存在的问题维护不同工具之间数据一致性非常困难、低效。并且这里不仅仅是工作量的问题,更大...
            14 13 849
            分享
          •   我们不应该仅仅局限于某一种工具,性能测试能使用的工具非常多,选择适合的就是最好的。笔者已经使用Loadrunner进行多年的项目性能测试实战经验,也算略有小成,任何性能测试(如压力测试、负载测试、疲劳强度测试等)都可以使用该工具。但我并不鼓励这样做,我们应该根据当前所处的情况,基于被测对象、时间及成本考虑,采用最合适的工具。闲话少谈,今天笔者要给大家分享的是用Jmeter来进行HTTP接口的压力测试。实际接口测试还可以使用Tsung、SoapUI等工具,但基于各方面考虑,最终采用了Jmeter。  Jmeter相对于Loadrunner来说,更轻,易于安装,如果对过程数据收集不多、测试场景...
            0 0 765
            分享
          •   任何的测试工作都可以从测试人员、覆盖范围、潜在问题(bug)、测试活动和测试评估五个维度进行描述。  测试人员:谁要做测试?  覆盖范围:什么东西需要测试?  潜在的问题:为什么进行测试(测试的风险是什么)?  测试活动:你如何测试?  测试评估:如何判断测试是通过还是失败?  测试任务通常分配在一个维度上,但你需要在所有五个维度上完成工作。  例如,有人可能会要求你做功能测试(彻底测试每个功能),这是告诉你要测试什么。  但由谁来进行测试,寻找什么类型的bug,如何测试每个功能,以及如何决定程序是通过还是失败都需要在测试任务启动时考虑。  本文主要从这五个维度对测试这门活动/技术进行分类...
            13 13 1822
            分享
          •   随着产品的不断升级,软件测试人员在研发团队中的比重越来越大,因为前期发展较晚,所以目前这方面的人才缺口很大。  1、测试人员是保证企业赖以生存的关键;  先来看一个因为测试人员的疏漏能给企业造成巨大损失的案例,最有代表性的就是2019年“拼多多100元无门槛消费券”漏洞,由于项目测试不到位,导致很多用户仅用了0.4元就给自己充值了100元的话费,事件虽发生在半夜,但是拼多多依旧损失严重,网络流传损失金额达200亿元,很多人担心拼多多就此倒闭。  这件事也给了企业重重一击,也让他们认识到测试的重要性,这件事不只是个例,每年企业因为测试没有做到位而造成的损失的事件早已屡见不鲜,也再次印证了测试...
            0 0 645
            分享
          •   Twitch 正尝试推出类似抖音的视频浏览方式,该公司正在测试一种名为“发现”(discovery)的功能,可以让用户在垂直滚动的视频流中浏览 Twitch 创作者的视频片段。  该功能将于周二开始向“部分用户”推出,Twitch 在 X 上发表了一篇文章介绍了这一功能。目前,“发现”功能只会显示水平方向的视频片段,Twitch 表示用户将在“功能发展”后看到垂直方向的视频片段。“发现”功能目前包括“精选”(featured)和“热门”(popular)两种类型的视频片段,创作者可以标记他们想要加入“精选”池的视频片段。  IT之家注意到,此前 Spotify、Amazon 和 Reddi...
            0 0 599
            分享
      • 51testing软件测试圈微信