容量保障核心技术与实战
吴骏龙
前阿里巴巴本地生活 P8 高级专家
5387 人已学习
新⼈⾸单¥29
登录后,你可以任选2讲全文学习
课程目录
已完结/共 19 讲
容量保障核心技术与实战
15
15
1.0x
00:00/00:00
登录|注册

02 | 容量测试与验证:怎样科学实施容量测试?

你好,我是吴骏龙。今天我会和你分享容量测试与验证的话题。
相对于性能测试和压力测试这些耳熟能详的名词,“容量测试”这个词也许你是第一次听到。在百度、Google 上一搜,结果倒是不少,但很多解释过于陈旧,并没有跟上互联网的发展速度。比如:
容量测试就是以压力测试的方式对服务施压,在相关容量指标达到瓶颈时停止,这时探测到的系统水位就是最大容量。
这个解释本身没什么毛病,我们很多时候也会把容量测试直接叫做压力测试,但有几家公司在执行容量测试时会真的压到瓶颈呢?如果你以这样的定义践行容量测试,在微服务体系下几乎是落不了地的。因为很多时候,我们并不需要去探测服务的容量极限。
其实,问题的本质在于,传统对容量测试的认知都希望能够获得一个瓶颈点,这是以压测的视角来看待它的。但绝大多数时候,我们都是根据预先制定的容量目标,通过对服务施压来观察和验证服务能否承载这一目标,并不是非要压出极限值。
我个人非常喜欢阿里前任 CTO 行癫在 2018 年双 11 启动会上说的一句话:“容量测试是验证手段,不是测试手段”。 换句话说,我们应该先努力设计和建造出满足容量要求的服务,再通过容量测试去验证它,而不是靠容量测试去反复探测服务容量瓶颈,再去不停地优化服务或扩容。我认为这才是对容量测试的现代化理解。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

容量测试与验证是一项重要的技术话题,相对于性能测试和压力测试,容量测试可能是一些人第一次听说。传统对容量测试的认知都希望获得一个瓶颈点,但现代化理解认为容量测试是验证手段,不是测试手段。在进行容量测试前,首先要确定测试的范围,包括专项场景和日常场景的服务。科学实施容量测试需要设计测试方案并进行评审,确保测试模型和数据合理,没有遗漏关键信息。容量测试工作需要全局视角,协作各个团队,以确保容量测试的全局流程。容量测试不是极限保障,而是有备而来的验证手段。 容量测试的实施过程包括测试准备、测试执行、测试反馈和持续跟进等六大工作内容。在测试准备阶段,需要根据评审过的场景撰写测试脚本,准备测试数据,并确保能够正常执行,服务无异常。在测试执行阶段,需要逐步对目标服务施加压力,严密监控各项指标,并在达到容量目标值后进行适当的摸高和脉冲,或对限流进行验证等工作。测试反馈阶段需要总结测试过程中的各项指标和数据,编写测试报告,输出结论。持续跟进阶段需要有效跟进暴露的问题,并在一定时间内跟踪解决,改进后确定时间再次进行验收,确保改进措施有效。 另外,文章还介绍了一种基线容量测试的方式,能够在测试环境以较低的成本先“定性”的识别出容量差异,以便提前发现可能存在的容量隐患。基线容量测试虽然没有办法对服务的容量进行定量分析,但可以一定程度上提前发现潜在的容量隐患,而问题早发现的修复和优化成本是最低的。 总的来说,本文详细介绍了容量测试的定义、范围和实施过程,提供了一套科学高效的容量测试流程,并探讨了基线容量测试的实施方式。文章内容丰富,适合技术人员快速了解容量测试的重要性和实施方法。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《容量保障核心技术与实战》
新⼈⾸单¥29
立即购买
登录 后留言

全部留言(4)

  • 最新
  • 精选
  • 金时
    虽然说"容量测试是验证手段,不是测试手段",但一个服务的SLA不还是测试出来的吗?

    作者回复: 我们并不反对“测试”这个行为,我们鼓励带着目标去测试(即验证),鼓励为了达到目标而做的改进工作先于测试进行,而不是纯粹靠测试去倒推这些改进工作。

    2021-09-18
    3
  • 于加硕
    看到这一章,发现吴老师的容量保障思路是容量测试,通过压测检验当前系统能否承载输入的用户量,目前看到这里,还没有考虑资源利用率的问题。 另外同时也咨询下“基线容量测试”又在实践的吗?

    作者回复: 你好,容量测试是一种验证手段,服务自身的优化和治理是需要前置的。资源利用率其实已经隐含在了容量保障的目标中,在第一章中我有提到:“服务容量充足,指的是服务的各项资源消耗和业务指标保持在一个相对安全的范围内”。也就是说,我们检验当前系统能否承载期望的访问量,是在资源利用率不出现瓶颈的情况下所实现的,例如某接口压到1000TPS时,CPU利用率不能超过90%。 关于基线容量测试,我们有一些团队在实践,效果还是不错的,如果有疑惑的话我们可以进一步交流。

    2022-06-21
    1
  • 声东击西
    混合容量测试在jmeter中怎样设计应用工具中,需要什么插件会怎么设计???

    作者回复: 你好,如果你指的“混合容量测试”是多场景的容量测试的话,可以使用JMeter的TestPlan,在里面放置多个线程组(Thread Group)来达到目的。如果想要一些更高级的功能(比如某个场景延迟一会启动,等),可以参考第七讲的工具实现原理。

    2023-09-30归属地:山东
  • Geek_722d27
    针对待发版的服务进行容量测试验证,验证通过隔离环境流量回放实现。根据本次回放各核心指标的与基线指标对比,来进行性能diff。
    2024-03-20归属地:北京
收起评论
显示
设置
留言
4
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部