fox 老哥牛逼

第一反应：这是哪来的算法题

很多呀，稍微知名一点的基本上都能给这个价格，不过主要是看 base

还是我没有表现出来了，这块自我 pua 一下，复盘好自己再注意就好了

然后，我这才 3 年多的经验，做测试管理的经验当然还是比较欠缺的，只能说持续进步了，哈哈哈，感谢大佬的回复

所以我想请教一下稀饭大佬，我这样的面评还有机会被捞起来么

emm，确实是，但是我在面试中没有把这块充分表现出来。
我之前在做过大促的质量 owner，当然是有整合过多个业务线的测试的资源，把控整体的研发进度（主要是排除交付风险），为最终的交付做最终的负责。但是面试官在面试过程中，并没有对这块细究，我好像也没有对这块深入说明。

至于业务的深度思考，面试官其实和我聊了当前业务的痛点是什么，然后我就从安全、高可用出发，具体说了之前的痛点，然后做了什么，然后之前的痛点解决了。然后现在的痛点是什么，为什么当前的痛点是这个，然后我们当前遇到了什么问题，我们做了什么样的事情去尽量解决这样的痛点。

估计面试官是觉得我说的和他理解的不一致吧。

感谢～那看来已经洗刷了之前面评了，但是现在又打上了新的污点标签，哈哈哈

令我没想到的是 1 面竟然过了

90% 无了吧

是的，后悔没写了，其实努努力是可以写出来的，难受

？？？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.百亿级倒百万级的数据压测，是为了优化压测平台的存储本身，不过我们最终的目的是要支持各种性能测试。
数据量的变化肯定会影响数据本身，做了一轮的数据压测会损失数据精度，不过损失的这个精度是业务能够容忍的。

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

大佬，base 深圳可以嘛

深入业务去做质量保障