考试查分场景重保背后,我们如何进行可用性测试

这篇具有很好参考价值的文章主要介绍了考试查分场景重保背后,我们如何进行可用性测试。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

作者:暮角

随着通过互联网音视频与知识建立连接的新学习方式在全国范围内迅速普及,在线教育/认证考试的用户规模呈井喷式增长。但教育容不得半点马虎与妥协,伴随用户规模不断增长,保证系统稳定性、有效避免千万考生考试时遭遇故障风险,成为行业认证机构/部门解决的首要难题。

在某次行业认证考试后,考生登陆查分系统时遭遇白屏、卡顿等问题。因此,行业认证机构/部门开始探索系统稳定性评估的路径。不同于传统线下行业可模拟出对等的生产环境,在线教育/行业认证的压测难以实现同级别的服务集群。数据构造不真实、场景不符实际使用都会造成压测任务与真实场景的偏差。此外,压测工具缺乏安全性、人力成本、IT 成本投入大等问题亦亟待解决。因此,想要完美承受高压检验,就需要进行细致的调研与准备工作。

为了帮助更多在线教育、认证机构/部门避免以上问题,我们完整复盘如何进行一次完整性能测试,涵盖部署架构资源风险输出与优化、应用实时监控与告警(可观测性)、系统容量评估与性能优化(压测)、活动远程保障与事后项目复盘。

第一步:需求调研与目标制定

为了更好的协调多方力量及保证项目执行足够聚焦,先设定一个业务目标。面对一个存在“白屏、卡顿”等问题的 Web 系统,与业务团队沟通初步制定「系统可以支撑 5 万 QPS 访问量」的目标。由于即将来临新的业务高峰,本次压测的初衷并不是在两周内对应用系统进行大幅度技术改造,而是通过压力测试发现应用的重大性能瓶颈并对之进行优化改造,并通过流量摸高方式了解系统真实服务能力,辅以分流等手段保障服务的可用性。

第二步:资源评估

(一)工具评估

进行高并发服务保障,除了对应用的服务能力进行一定扩容之外。由于行业认证机构/部门此前在云上未进行过压力测试,因此需要购买压测工具以及相应的监控工具,这里使用了阿里云性能测试 PTS、应用实时监控服务 ARMS,这里需要注意的是:

  • 性能测试 PTS, 工具本身不收费,根据流量进行收费,所以需要根据压测规模、压测目标、压测次数,提前预估压测资源包的额度。首次开通性能测试 PTS,赠送 5000 VUM 免费额度,可以用来帮助团队熟悉工具的使用或进行初次测试。
  • 应用实时监控服务 ARMS, 目前按照数据写入量进行计费,提供每个月 50 GB 免费额度,这个数据写入量与 JVM 进程数量、存储时间相关,免费额度基本满足本次压测需求。
  • Web 应用防火墙 WAF, 由于本次压力测试是在真实生产环境进行,流量会过 WAF。由于 WAF 按照流量计费,压测目标超过用户所购买的 WAF 规格包。WAF 3.0 版本,当前规格带宽 100M,5K QPS,压测目标 5 万 QPS,超出部分按量计费,不使用不收费,按 45K QPS 估算,0.15/QPS/天,按 3 次压测+分数查询首日,共 4 次预估费用 2.7 万元。

(二)资源梳理

  • 与研发团队对齐业务系统架构、业务资源容量情况及压测环境、压测工具和业务接口信息沟通。
  • 关键业务接口梳理完成 (非全量,关键 API)。
  • 重保压测资源与费用评估。以 5 万 QPS 为目标,系统压力测试费用评估,包括测试所需的 ECS 、PTS、ARMS、WAF 等费用。
  • 确定最终资源使用规划。按生产等比配置测试环境,机器数量 6 台,升级新购资源费用,初步费用评估完成。

第三步:压测摸高

(一)第一轮压测:问题初现

在完成压测环境、系统数据准备以及压测场景配置之后。开通 ARMS 完成 Java 应用接入,同时提供压测环境的服务器清单,开始 PTS 压测环节。其中,因为域名所属行业特殊,PTS 压测域名需要开白才可以。我们开始第一轮压测。

【压测结果】

「登录-查分」并发用户数 3000,平均 RT 1631ms,平均 TPS 1964,错误数 1.7 万。

考试查分场景重保背后,我们如何进行可用性测试,可用性测试,阿里云,云原生,压测

【问题发现】

应用压测过程中有大量的 5s 超时问题,后续调整 PTS 超时时间。

考试查分场景重保背后,我们如何进行可用性测试,可用性测试,阿里云,云原生,压测

【问题发现】

概览所有环节中,验证码环节耗时最长,RT 平均能达到 7s 。

考试查分场景重保背后,我们如何进行可用性测试,可用性测试,阿里云,云原生,压测

调整 GTM 主备配置互换,启动第一轮压测,最高 3K QPS 不及预期。同时,调整 tomcat 应用连接池大小至 4096。因为与生产环境共用,只能业务空闲时间进行压测,导致压测进度与预期不符,调整 SLB 转发规则并指向测试服务器组。同时,阿里云建议后续研发团队可将验证码信息存储到 Redis 中来提升性能。从压测情况看研发侧优化效果较好,但 RT 波动较大。云原生应用平台团队给出一些优化建议后,RT 波动问题明显改进。

考试查分场景重保背后,我们如何进行可用性测试,可用性测试,阿里云,云原生,压测

(二)第二轮压测:持续改进

在优化了一些中间件优化之后,我们基本逐渐提升并发用户数继续进行第二轮测试,并持续改进。

【压测结果】

「登录-查分」并发用户数 1 万,平均 RT 1560ms,平均 TPS 6082,错误数 6.2 万。

考试查分场景重保背后,我们如何进行可用性测试,可用性测试,阿里云,云原生,压测

「登录-查分」并发用户数 2 万,平均 RT 2916ms,平均 TPS 6831,错误数 3390。

考试查分场景重保背后,我们如何进行可用性测试,可用性测试,阿里云,云原生,压测

【问题发现】

通过对比测试,我们发现应用承载能力就是 1 万并发用户数、平均 RT 1.5s。提升 1 倍并发用户后,服务器平均 TPS 没有提升,只是 RT 增加了 1 倍。

针对上述问题,研发团队进行了优化。通过在内网使用 Jmeter 测试,看到单台服务器性能有明显提升,并发现 Redis 存在可优化点。进一步分析发现,很多慢请求都是访问用户的自建 Redis,但研发团队反馈 Redis 延时很小,并且切换到阿里云 Redis 后未发现改进。因为之前验证码环节性能很差,压测环境都跳过该环节。目前这部分优化已经完成,在测试增加了验证码环节。验证码环节压测需要特殊配置,配置好后继续测试。当天结果瓶颈还未找到,QPS 稳定在 1.2 万、RT 2-3s,再加大压到 5 万,无明显改善。

(三)第三轮压测:问题突破

因为目前整体服务承载能力多次优化后,稳定无法提升,阿里云建议尝试通过增加服务器数量压测,由此判断是应用服务器性能,还是数据库服务器性能导致目前瓶颈。如果横向扩展应用服务器性能能提升,就是应用服务器问题,否则就是数据库这种单点服务的问题。应用服务器从 6 台增加到 8 台,服务能力并未看到线性上升,QPS 增加到 1.3 万左右。结合此现状,可以判断是单点问题限制,推断可能是 Oracle 数据库、Redis,但研发团队反馈压测时两个产品链接不多,响应速度在毫秒级。经过对压测报告的分析,发现滑块验证处理比较慢,耗时较长,研发团队将滑块验证改为字符验证码。并发起新一轮的压测。

考试查分场景重保背后,我们如何进行可用性测试,可用性测试,阿里云,云原生,压测

【压测结果】

添加 Redis 后,3 万用户,3 分钟,性能几乎翻倍。

「登录-查分」并发用户数 3 万,平均 RT 1514ms,平均 TPS 20145,错误数 2960。

考试查分场景重保背后,我们如何进行可用性测试,可用性测试,阿里云,云原生,压测

「登录-查分」并发用户数 5 万,平均 RT 4552ms,平均 TPS 13744,错误数 21.6 万。

考试查分场景重保背后,我们如何进行可用性测试,可用性测试,阿里云,云原生,压测

考试查分场景重保背后,我们如何进行可用性测试,可用性测试,阿里云,云原生,压测

【问题发现】

通过对比测试,发现应用服务器的承载能力在翻倍提升后,稳定在 2 万 TPS。即便把并发提升到 5 万,该指标也未能再继续提升。Redis 扩容后(64c 128g *3),性能提升 1 倍,RTS 稳定在 2.2 万,RT 1-2s 。尝试使用阿里云 Redis(7c8g 4db)压测,但与自建 Redis 相比规格小太多,测试结果性能提升不大。

应用 8 台服务器最高 QPS 到 2.5 万,按照 5 万 QPS,届时分流需要拆分 2.5 万到静态页面。测试压测单台分流服务器静态页面 RTS 支撑能力为 4 万,静态页面使用 404 页面是否合理待评估。「

登录-繁忙」并发用户数 2.5 万,平均 RT 582ms,平均 TPS 41772,错误数 10.9 万。

考试查分场景重保背后,我们如何进行可用性测试,可用性测试,阿里云,云原生,压测

SLB 负载不均是健康检查失败导致的,静态页返回 404,SLB 层面不会抑制请求转发,会正常分发请求给该应用服务器。

第四步:上线保障

在上述多轮压测以及优化之后,我们进行最后一轮压测:业务服务器+静态页面 压测达到预期业务目标 5 万 QPS,按 3 : 1 比例分发请求,度过业务高峰后快速关闭静态页服务器。

【压测结果】

「登录-查分」并发用户数 2.5 万,平均 RT 1030ms,平均 TPS 22965,错误数 44(6 台生产机器总体处理能力)。

考试查分场景重保背后,我们如何进行可用性测试,可用性测试,阿里云,云原生,压测

「登录-查分」并发用户数 2.5 万,平均 RT 396ms,平均 TPS 64887,错误数 72.2 万。

考试查分场景重保背后,我们如何进行可用性测试,可用性测试,阿里云,云原生,压测

【压测摸高】

10 台应用服务处理能力最高 2.5 万 TPS,其中 3 台应用服务器上同时部署静态页面,应用程序和静态页面权重比例 1 : 1压测。并发 4 万、RT 396ms、TPS 64887ms、达到预期目标 5 万 TPS。最后一次持续高并发压测,并发 2.5 万,RT有抖动,TPS 维持在 2 万,成功率 99% 以上。通过最后的压测结果,结合资源现状进行保障方案落地:开放查分入口首日,静态页面与应用程序权重比例调整为 100 : 30 ,总体处理能力 3 万 TPS。

【开放查分】

晚 23 时开放查分,流量小于预期,系统平稳运行度过峰值 QPS 1.6W。

考试查分场景重保背后,我们如何进行可用性测试,可用性测试,阿里云,云原生,压测

第五步:优化总结

经过多轮的压测以及前期优化,应用及架构找到多个瓶颈点并进行改造优化,比如验证码模块性能差、单 Redis 改为集群 Redis、应用多线程处理能力、业务处理能力随资源增加而线性提升等都进行相应的验证和优化。在现有条件下,优化后的应用和架构的健壮性大幅提升,积累了该应用的资源容量评估经验,后续可以随着业务量增减,有数据依据的增减资源,日常保持好水位线即可。同时,我们梳理了诸多日常优化方案,其中包括:

一、安全风险预警。

重保期间请求流量尚未经过 Web 应用防火墙,缺失常见攻击防御能力,后续考虑请求流量过 WAF 且动静资源分离,静态资源通过 CDN 加速分发。一方面,减轻业务服务器对静态资源处理压力和带宽压力;另一方面,有效降低 WAF 带宽压力与成本。

二、数据库产品存在单点风险与升降配不灵活问题。

在 ECS 云服务器上的自建 Oracle 数据库存在单点故障风险,一旦单个服务出现异常整个平台会彻底不可用。自建的 Oracle 数据库与 Redis 服务,无法灵活改配,不便于日常使用与重保期间进行能力切换。后期计划通过改造使用云上的数据库,加强可用性的同时,灵活升降配,进一步贴近当前业务需求。

三、应用存在大规格服务器资源无法利用问题。

目前应用单体架构耦合度高,无法经济的单独部署更多涉及性能瓶颈的模块。后续计划对应用内部模块进行拆分,以便让应用可以有更合理的部署架构。另外,针对目前问题,后续重保期间扩容的应用服务器采用更多低规格服务器来提升性能。从现在的 64C128G 变为 16C32G,从而获得 4 倍应用服务能力。

四、在日常研发中使用 PTS 进行持续压测。

通过本次重保压测,研发团队已经在阿里云 PTS 产品团队支持下充分掌握该工具的使用方法。该工具拥有的快速创建多地压测节点的能力充分利用的阿里云平台的多地域优势,能快速模拟实际业务场景进行全链路压测,大大的节约了应用问题发现与改进时间。是本次重保环节中的核心功臣。

五、继续在日常应用服务环节使用 ARMS 监控。

通过 ARMS 应用监控,在压测过程中发现很多细节问题,为快速的定位问题提供极大便利,大大提升问题定位效率,是不可多得的运维必备工具。

第六步:查漏补缺

一、PTS 是一款非常容易上手且便捷的压力测试工具,使用 PTS 可以迅速提升测试效率;

1)使用自带的录制控件可以快速录制场景,自动捕捉需要压测的接口;

2)产品公共云值班同学能耐心给予产品问题解答,即便是新手也可以立即上手使用;本次测试过程中,研发团队是第一次使用该产品,交付团队也不是熟手,但是使用十分丝滑,整个过程中并未觉得不顺手;

二、通过压测发现系统瓶颈的过程是一个持续寻找问题的过程,压测能给系统压力然后暴露出系统的瓶颈;

1)单 Web 服务器并发能力需要第一步得到答案。分布式架构或者单体架构都没关系,重要的是要获取每个服务角色的单机能力。服务器的规格并不是越大越好,比如这次我们最后都无法给予一个 64C128G 的 Web 服务器超过 50% 压力,合适的规格是业务规划最重要的评估项。

2)确认单 Web 服务节点的能力后,就可以提升服务器数量进行整体压测,这样扩展下去就能知道在达到压测目标的情况下,每个服务器角色需要多少台。除非是严重的 Web 服务角色节点性能问题,短期内提升服务器数量都可以大规模提升服务能力。

3)想要更快的暴露系统架构中的单点瓶颈,可以横向扩展的服务器扩展到一定规模。这种单点瓶颈一般就是数据库,例如关系型数据库、缓存数据库、分布式数据库。如果压测到单点瓶颈,优化关系型数据库最简单的方式就是提升服务器规格;如果无可提升就需要使用读写分离来分担压力。如果使用可以横向扩展的数据库,就可通过扩容节点来提升能力,使系统整体服务能力提升。在高并发场景下,使用内存数据库无疑是提升能力的快速通道,尤其是考试查分这种只读场景。

三、短时间内能做的事情十分有限,重保这种高并发场景要做的就是保障系统可用性;

1)我们本次压测的系统是一个适用于传统自建 IDC 机房并有一定技术历史包袱的系统,采用 Windows + Oracle + 单体架构,想要在短期内改变架构很难。为了保障近期重要的高并发场景,研发团队聚焦于把解决严重的性能缺陷,扛过保障时点。

2)服务分流是保障系统可用性的最简单手段,8 台 Web 服务器测试得到的应用最高 QPS 才 2 万余,单台 Web 服务器能承载的繁忙页 QPS 就能达到 1 万 QPS。所以,关键时刻保障部分用户可用即可。在完全不可用与排队间取舍,一起排队用已是最优解。

3)上线前一定要做好保障演练。前端 SLB 最大能承载的流量就是 5 万 QPS,这也是本次演练的目标。因此设计了正式应用服务器承载 3 万 QPS 流量,繁忙页承载 2 万 QPS 流量,在 SLB 端配置权重比例。ARMS 应用监控是秒级监控且调整 SLB 权重实时生效,但只对新连接请求生效,原有长连接不受新权重影响。文章来源地址https://www.toymoban.com/news/detail-816856.html

到了这里,关于考试查分场景重保背后,我们如何进行可用性测试的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 解读数据可用性赛道:如何讲好模块化区块链的叙事?

    数据可用性(Data Availability)主要存在于轻客户端节点相对全节点的语境下。对于轻客户端节点的数据可用性问题,行业内已经达成共识——采用纠删码(erasure codes)来解决。 不仅轻客户端节点有数据可用性问题,Layer1+Layer2 的叙事也好,Modular Blockchain 的叙事也罢,都会存在

    2024年02月08日
    浏览(38)
  • 分布式系统的容错性和可用性该如何保证?——云计算高手的指南

    作者:禅与计算机程序设计艺术 云计算的快速发展给我们带来了巨大的机遇。不仅如此,云计算还解决了一些复杂的问题,比如资源共享、弹性伸缩等问题。但是,云计算也引入了新的复杂性,比如分布式系统的容错性、可用性等问题。如果分布式系统不能很好的处理容错性

    2024年01月19日
    浏览(49)
  • 如何利用容器与中间件实现微服务架构下的高可用性和弹性扩展

    本文分享自天翼云开发者社区《如何利用容器与中间件实现微服务架构下的高可用性和弹性扩展》,作者:c****w 在当今的互联网时代,微服务架构已经成为许多企业选择的架构模式,它能够提高系统的灵活性、可维护性和可扩展性。然而,微服务架构下的高可用性和弹性扩展

    2024年01月19日
    浏览(65)
  • 如何保证分布式系统中服务的高可用性:应对 ZooKeeper Leader 节点故障的注册处理策略

    作者:zhaokk 在现代分布式系统中,高可用性是一个至关重要的。分布式系统中的各个组件需要保证在各种异常情况下仍然能够正常工作,确保系统的稳定性和可靠性。ZooKeeper(以下简称为zk)作为一种常用的分布式协调服务,为分布式系统中的各种任务提供了基础支持

    2024年02月11日
    浏览(64)
  • 图形背后的故事:数据可视化如何改变我们的视角

    数据可视化,作为一种信息传递和理解的工具,已经深刻地影响着我们的生活。无论是个人生活还是社会运转,数据可视化都在为我们呈现更清晰、更直观的画面。下面我就以可视化从业者的角度,简单说说这个话题。 生活中,我们时刻与数据打交道,从每天的天气预报到社

    2024年01月25日
    浏览(42)
  • 高可用性架构:云计算和高可用性

    作者:禅与计算机程序设计艺术 引言 1.1. 背景介绍 随着互联网业务的快速发展,云计算已经成为了企业构建和部署应用的基本手段。云计算带来了便利、灵活性和可伸缩性,极大地推动了数字化时代的到来。然而,如何保障云上应用的高可用性,让云计算更好地为企业服务

    2024年02月15日
    浏览(47)
  • 什么是可用性测试?

    可用性测试(Usability Testing)是一种软件测试方法,旨在评估一个产品(如软件、网站、移动应用等)的易用性和用户体验。该测试方法通过让真实的用户执行特定任务,观察和记录他们的行为、反应和满意度,来评估产品的可用性和用户友好程度。 可用性测试的主要目标是

    2024年02月11日
    浏览(44)
  • 服务可用性设计

    一、统计指标 根据普罗米修斯Prometheus中的up指标,按照分钟记录服务不可用的记录数 up指标:up{application=“agr-ecos.admin”,instance=“30.79.8.41:43950”,job=“agr-ecos”} 当实例下线时为0,实例上线时为1 1、判断服务不可用逻辑 服务在某个分钟里,所有实例的up指标全为0,如果满足条

    2024年02月07日
    浏览(36)
  • selenium代理ip可用性测试

    测试代理ip是否工作正常,将正常的代理ip提取出来 测试结果

    2024年01月20日
    浏览(48)
  • 14.RocketMQ之高可用性机制

    RocketMQ分布式集群是通过Master和Slave的配合达到高可用性的。 Master和Slave的区别:在Broker的配置文件中,参数 brokerId的值为0表明这个Broker是Master,大于0表明这个Broker是 Slave,同时brokerRole参数也会说明这个Broker是Master还是Slave。 Master角色的Broker支持读和写,Slave角色的Broker仅支

    2024年02月11日
    浏览(44)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包