扁平化设计 网站,做问卷调查用哪个网站好,phpcms 恢复网站,做网站主图多少钱作者#xff1a;暮角
随着通过互联网音视频与知识建立连接的新学习方式在全国范围内迅速普及#xff0c;在线教育/认证考试的用户规模呈井喷式增长。但教育容不得半点马虎与妥协#xff0c;伴随用户规模不断增长#xff0c;保证系统稳定性、有效避免千万考生考试时遭遇故障…作者暮角
随着通过互联网音视频与知识建立连接的新学习方式在全国范围内迅速普及在线教育/认证考试的用户规模呈井喷式增长。但教育容不得半点马虎与妥协伴随用户规模不断增长保证系统稳定性、有效避免千万考生考试时遭遇故障风险成为行业认证机构/部门解决的首要难题。
在某次行业认证考试后考生登陆查分系统时遭遇白屏、卡顿等问题。因此行业认证机构/部门开始探索系统稳定性评估的路径。不同于传统线下行业可模拟出对等的生产环境在线教育/行业认证的压测难以实现同级别的服务集群。数据构造不真实、场景不符实际使用都会造成压测任务与真实场景的偏差。此外压测工具缺乏安全性、人力成本、IT 成本投入大等问题亦亟待解决。因此想要完美承受高压检验就需要进行细致的调研与准备工作。
为了帮助更多在线教育、认证机构/部门避免以上问题我们完整复盘如何进行一次完整性能测试涵盖部署架构资源风险输出与优化、应用实时监控与告警可观测性、系统容量评估与性能优化压测、活动远程保障与事后项目复盘。
第一步需求调研与目标制定
为了更好的协调多方力量及保证项目执行足够聚焦先设定一个业务目标。面对一个存在“白屏、卡顿”等问题的 Web 系统与业务团队沟通初步制定「系统可以支撑 5 万 QPS 访问量」的目标。由于即将来临新的业务高峰本次压测的初衷并不是在两周内对应用系统进行大幅度技术改造而是通过压力测试发现应用的重大性能瓶颈并对之进行优化改造并通过流量摸高方式了解系统真实服务能力辅以分流等手段保障服务的可用性。
第二步资源评估
一工具评估
进行高并发服务保障除了对应用的服务能力进行一定扩容之外。由于行业认证机构/部门此前在云上未进行过压力测试因此需要购买压测工具以及相应的监控工具这里使用了阿里云性能测试 PTS、应用实时监控服务 ARMS这里需要注意的是
性能测试 PTS 工具本身不收费根据流量进行收费所以需要根据压测规模、压测目标、压测次数提前预估压测资源包的额度。首次开通性能测试 PTS赠送 5000 VUM 免费额度可以用来帮助团队熟悉工具的使用或进行初次测试。应用实时监控服务 ARMS 目前按照数据写入量进行计费提供每个月 50 GB 免费额度这个数据写入量与 JVM 进程数量、存储时间相关免费额度基本满足本次压测需求。Web 应用防火墙 WAF 由于本次压力测试是在真实生产环境进行流量会过 WAF。由于 WAF 按照流量计费压测目标超过用户所购买的 WAF 规格包。WAF 3.0 版本当前规格带宽 100M5K 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 。尝试使用阿里云 Redis7c8g 4db压测但与自建 Redis 相比规格小太多测试结果性能提升不大。
应用 8 台服务器最高 QPS 到 2.5 万按照 5 万 QPS届时分流需要拆分 2.5 万到静态页面。测试压测单台分流服务器静态页面 RTS 支撑能力为 4 万静态页面使用 404 页面是否合理待评估。「
登录-繁忙」并发用户数 2.5 万平均 RT 582ms平均 TPS 41772错误数 10.9 万。 SLB 负载不均是健康检查失败导致的静态页返回 404SLB 层面不会抑制请求转发会正常分发请求给该应用服务器。
第四步上线保障
在上述多轮压测以及优化之后我们进行最后一轮压测业务服务器静态页面 压测达到预期业务目标 5 万 QPS按 3 : 1 比例分发请求度过业务高峰后快速关闭静态页服务器。
【压测结果】
「登录-查分」并发用户数 2.5 万平均 RT 1030ms平均 TPS 22965错误数 446 台生产机器总体处理能力。 「登录-查分」并发用户数 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 权重实时生效但只对新连接请求生效原有长连接不受新权重影响。
