31 | 容量场景:决定线上容量场景的关键因素是什么?
高楼
你好,我是高楼。
上节课,我们对场景进行了一个预压测,提前解决了一些基础性的问题。这节课呢,我们就可以直接上大的压力来执行容量场景了。容量场景的目的就是验证线上环境能不能满足需求,最后给我们一个明确的答案。
通常在真实的项目中,我们都会有总 TPS 的需求,也会有详细的 TPS 需求(每个接口应该在多长的响应时间内达到多少 TPS)。在第 3 讲的压测方案中,我们已经有了一个指标表,我也把它直接放在下面了。
这里的目标 TPS 都加在一起是 1350,后面响应时间也给出了个大概的值(200ms 以下),这也算是个比较明确的指标了。下面我们就通过容量场景来看看这个目标能不能达到,要是能达到,我们就可以给出“测试通过”的结论了。
下面我们先运行一下容量场景,这里用 JMeter 或 GoReplay 来运行都是可以的。
不过在这之前我们得知道,虽然在前面的预压测中,我们有过把 TPS 调到 900 左右的时候。但是现在环境也经过了好几轮的折腾,各应用也重启过好几次了,我们不知道各个服务是不是还是在预压测的那个状态。
这也是我们在性能项目中经常会面对的问题:有些指标在之前执行的场景中一切良好,但在解决其他问题的过程中,突然就出现了性能变差的情况。这种情况经常会随机地出现,所以如果有性能工程师把某一次压力良好的数据直接当成最终的性能结果,就这样把它写进性能报告里,这肯定是应付差事的表现。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了容量场景的关键因素和在线上容量场景执行过程中可能遇到的问题。作者首先强调了容量场景的目的是验证线上环境是否能够满足需求,并给出明确的答案。在执行容量场景之前,需要考虑环境的变化对性能的影响,以及如何解决性能衰减的问题。文章提到了在容量场景中出现性能衰减的情况,并对压力场景数据进行了分析,指出了TPS下降和响应时间增加的问题。作者还介绍了性能分析七步法和全局监控分析的重要性,以及在微服务分布式架构中如何查看全局监控计数器。全文围绕容量场景的执行过程和问题分析展开,为读者提供了一些性能工程方面的实用知识和经验。文章通过具体的数据分析和解决问题的实例,为读者呈现了容量场景执行过程中可能遇到的挑战和解决方案,对于从事性能工程的技术人员具有一定的参考价值。文章内容涉及Arthas跟踪接口代码、性能分析七步法、全局监控分析、数据库SQL执行效果、JDBC连接池调整等方面,为读者呈现了丰富的技术内容和解决问题的思路。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《全链路压测实战 30 讲》,新⼈⾸单¥59
《全链路压测实战 30 讲》,新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(3)
- 最新
- 精选
- Geek_f9e0e5环境资源和全链路测试需求分析,就是已知的大难题了
作者回复: 再难也得干不是。
2022-02-111 - 尘缘如梦66老师,这个地方:us CPU 在 66% 左右,sy 在 20% 以下,这两个部分是挺正常的数据了。但 si CPU 达到了 16%,这就有点高了。我们可以先从这里往下找,查看软中断计数器(注意这个值是累加值),我有两个问题: 1.CPU66%了,为啥不先去分析CPU呢 2.si占比高,我们实际中该如何确定这个si高还是不高呢,有没有统一的标准呀
作者回复: 1. 对一个服务器来说,us cpu本来就应该在压力大的时候高才对。如果没有其他的CPU有问题,那再来收拾us cpu也不迟。 2. 没有统一的标准。在我的工作中,通常超过10%就要关注了。
2022-03-04 - Geek_62d00d老师请教您一个问题就是:1.第一阶段带宽存在问题,为啥要更换性能更好的IO存储设备呢?
作者回复: 带宽高是因为传输的内容多,传输之后本地就是要读写,就需要更好的IO存储设备了。
2022-02-09
收起评论