？？？30k 那么好拿嘛，我出去接过最高的才 27k

哈哈哈，我也跑了大半年，今年跑了 300 多公里，至今不敢挑战半马

发现最近身边的人，要不开始跑马拉松，要不开始健身了 。

请问可以 base 广州深圳么？

我们一般是这样的的：
1.和产品运营沟通，预期的 pv，uv 是多少，根据转化到后面的页面的比例是多少。我们初步按照这个计算总体的请求量。
2.获取到总的请求量之后，我们按照页面的总请求量计算 qps（注意高峰期的计算），分配到不同的接口，获取各个接口的 qps。
3.根据接口的 qps，按照一定的冗余去压测。冗余根据情况可以是 3 倍，5 倍，10 倍。主要还是根据接口的初识 qps 去设置的。

那可以自己写一个压测引擎，难度也不大

菜🐔流泪

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

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

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