容量保障核心技术与实战
吴骏龙
前阿里巴巴本地生活P8高级专家
新⼈⾸单¥55
432 人已学习
课程目录
已更新 4 讲 / 共 16 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词 | 互联网时代,人人肩负容量保障的职责
免费
基础篇 (3讲)
01 | 容量保障的目标:容量保障的目标是什么?该如何度量?
02 | 容量测试与验证:怎样科学实施容量测试?
03 | 容量指标分析经典5问:响应时间真的是越短越好吗?
容量保障核心技术与实战
15
15
1.0x
00:00/00:00
登录|注册

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

吴骏龙 2021-05-14
你好,我是吴骏龙。今天我会和你分享容量测试与验证的话题。
相对于性能测试和压力测试这些耳熟能详的名词,“容量测试”这个词也许你是第一次听到。在百度、Google 上一搜,结果倒是不少,但很多解释过于陈旧,并没有跟上互联网的发展速度。比如:
容量测试就是以压力测试的方式对服务施压,在相关容量指标达到瓶颈时停止,这时探测到的系统水位就是最大容量。
这个解释本身没什么毛病,我们很多时候也会把容量测试直接叫做压力测试,但有几家公司在执行容量测试时会真的压到瓶颈呢?如果你以这样的定义践行容量测试,在微服务体系下几乎是落不了地的。因为很多时候,我们并不需要去探测服务的容量极限。
其实,问题的本质在于,传统对容量测试的认知都希望能够获得一个瓶颈点,这是以压测的视角来看待它的。但绝大多数时候,我们都是根据预先制定的容量目标,通过对服务施压来观察和验证服务能否承载这一目标,并不是非要压出极限值。
我个人非常喜欢阿里前任 CTO 行癫在 2018 年双 11 启动会上说的一句话:“容量测试是验证手段,不是测试手段”。 换句话说,我们应该先努力设计和建造出满足容量要求的服务,再通过容量测试去验证它,而不是靠容量测试去反复探测服务容量瓶颈,再去不停地优化服务或扩容。我认为这才是对容量测试的现代化理解。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《容量保障核心技术与实战》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥55
立即订阅
登录 后留言

精选留言

由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论
返回
顶部