这里你可以自己写一个监听器呢～

存在几部分的问题吧
1.聚合处理并不优雅，这个迟点要继续优化。
2.其他同学写的混合场景大概有 200 个 sampler。
3.kafka 的 consumer 有 10 个左右，综合下来。
导致数据中心的聚合处理后的压缩比例达不到期望的那样。

非常感谢你的提问～
以下是我的个人理解
1.主要是为了存储压测数据，给用户实时展示使用。
2.当我们知道性能瓶颈在哪里的时候，我们就需要对他进行优化，优化的方式当然有多种，要找到适合自己的优化方式。
然后 jmeter 是个压测引擎，我们一开始使用的 influxdb 作为底层的存储。最后出现瓶颈之后，我们切换到了 clickhouse。在做底层存储切换的时候要考虑业务数据是否要做迁移，只要数据迁移做好了，其他倒没有什么问题。
3.百亿级倒百万级的数据压测，是为了优化压测平台的存储本身，不过我们最终的目的是要支持各种性能测试。
数据量的变化肯定会影响数据本身，做了一轮的数据压测会损失数据精度，不过损失的这个精度是业务能够容忍的。

前端基本上都是拿了各种组件过来用的，搭建很快

大佬，base 深圳可以嘛

深入业务去做质量保障