这不就是自测吗?把每个功能的主要用例都给开发测试,测试通过了才提测,能做到就不会存在功能没做了
好像 edge 也有一个集锦?和你这个差不多
还有个问题,agent 流输出的话,首字符开始后,后续各个字符之间的响应时间会再做分析吗?还是总的时间不超时就行?
还有一个老生常谈的问题——“拐点”。现在各种缓存、消息队列等中间件都比较成熟了,系统到达最大处理容量后 tps 一般会维持在高点附近,或者来回抖动,从图上很难看到真的 “拐” 的地方
"正确的做法应该是:第 1 秒内通过异步任务启动接口一次性触发 10 个任务后,便不再持续发压,观察系统能否在 10 分钟内完成这批任务。10 分钟后再通过异步任务启动接口启动 10 个任务,确保流水线中并发处理的任务数始终维持在 10 以内。"
这个不敢苟同,流量不一定按你所想的进来,确保系统能同时处理 10 个任务之外还得继续提交任务的,因为要验证系统的排队能力,即时不能并发处理过多的任务也要保持任务队列正常运行,或者说系统的限制功能正不正常,对应八股文中的最小线程数,最大线程数,队列长度,饱和策略等
good
像 jenkins 这种容器化的优势在哪里呢
byd 也能停业吗
怎么做的?监听到消息后怎么去和压测线程交互?
JMeter 这种同步线程的工具,没办法去做像 sse 这类需要异步监听的压测吧?