天启
老师你好，我想问下通过部署agent的方式来规避master-salve的痛点的话，压测机的启动方式是以jmeter-server方式的吗，还是说是用agent,动态的进行命令行方式jmeter -n xxxx动态启动压测？
作者回复：你好，启动方式是后者。我们完全放弃了JMeter的分布式执行策略，因此也就不再使用jmeter-server的启动方式，所有JMeter节点都视为是Master由平台统一调度。
2022-09-21
林林总总0107
看完老师的专栏，学习了很多，很多点会对我后续性能测试工作有帮助，值得推荐给小伙伴一起学习
作者回复：很高兴能为你带来收获，非常感谢支持和认可，我们共同持续学习
2021-10-29
勿更改任何信息
现在全链路压测基本上都是验证峰值QPS，如果想验证整天的创建订单量达到了一定的量级，有可能要压几个小时，甚至十几个小时，这个压测合适吗？
作者回复：你好，全链路压测不适合长时间的压测测试或稳定性测试，主要原因有两点：
1.全链路压测一般在生产环境的低峰期实施，如果时间过长，压测工作跨越到高峰期，容易造成不必要的风险。
2.全链路压测会产生大量的数据，也需要投入人力持续值守和监控，成本比较高，不适合长时间执行。
除此之外，绝大多数服务容量的瓶颈都发生在高并发和高吞吐量的场景下，对于需要进行长时间压测来检测的问题（如：内存泄露、GC问题、磁盘容量瓶颈等），一般在线下测试环境进行测试也已经足够了，即便线下测试不完整，这些问题也可以通过简单的线上监控提前感知到，因此在这些问题上引入全链路压测的性价比并不高。
2021-09-13
1
彬彬ieeeeemily
老师，向你请教个问题：
目前团队内想对公司核心业务做容量水位探测
内部搭建了一个nGrinder压测平台，没有全链路压测的基础设施，其他的监控告警设施、链路追踪都具备了
在这样的情况下，做容量测试，我想到的方案是 自动抓取峰值时刻的线上日志 做业务模型和数据模型，与nGrinder结合的方式进行容量测试压测，不知道这样是否可行？
作者回复：你好，抱歉回复较晚。在缺乏全链路压测基础设施的情况下（尤其是没有做数据隔离），单纯通过回放日志的方式，只能保证业务模型在一定程度上的准确性，但在实施阶段，难以满足“写请求”的压测，部分读请求可能也不行（若涉及鉴权等环节），只能对局部读请求做单链路压测。
2022-05-06
终身学习者
压测置信度的影响因素：
1.压测流量的构造是否接近真实用户流量
2.压测链路是否完全覆盖
3.是否加入了背景流量或者低流量调用
4.底层基础架构是否和线上保持一致或者相同，如数据库分片一致、存储集群相同等
5.外部依赖的第三方接口mock、模拟异常
6.流量模型是否和线上一致，如短时突增流量、较长时间稳定高流量等模型
作者回复：总结的很好，尤其是最后一点，非常考验功底
2022-01-07
于加硕
吴老师能否简单讲下回归分析和神经网络来做容量规划思路的区别？目前对于神经网络还没有研究过，在之前的调研中，没有发现有公司使用这种方案，大多采用回归分析；文中所说的因变量，自变量，模型，预测，评价模型优劣，与回归分析思路一致；
作者回复：原理上，两者都能处理“回归问题”，神经网络的重点是建立自变量和因变量之间的关系，而回归分析更关注这一关系的内部结构。就容量预测的问题来说，两者没有本质的区别（我们并不需要去解释这一关系的结构）。
2022-07-11
漂泊的松鼠
看你的照片，略显稚嫩，买专栏时有点犹豫，看完觉得文章质量远超预期，点赞
作者回复：非常感谢你的支持和认可：）
2021-06-23
2
于加硕
培养全局视野，会被解读为什么都懂，什么都不精。换个方向思考横向的知识面不算是一种精通吗！比如形成的容量保障体系。
后半部分有同感，通过单个服务验证想法，继而批量实现。
2022-07-20
牛减
大佬能否也开一门 质量保障 的？
作者回复：感谢厚爱和支持，质量保障是一个big deal，它的涵盖面比容量保障更广，我，包括其他老师，也都会以各种形式输出一些质量保障的方法和看法（不一定是专栏，可能是每日一课或其他形式），你可以多多关注
2022-02-19
dalek
我们目前也会采用一定的指标组合，比如业务与基础指标相结合，业务指标作为x轴，y轴为基础cpu idle，以此来确保仿真等内容…调用链路来分析请求错误也是一个比较不错的方式，但是分析成本比较高…
作者回复：很不错的实践分享，尤其是坐标轴的方式让人眼前一亮，向你学习！
2021-05-26
1
讲师
吴骏龙
前阿里巴巴本地生活 P8 高级专家
编辑推荐
包含这门课的学习路径
运维工程师
32门课程 149.1w人学习
看过的人还看了
