站在测试的角度，重要的还是对业务足够熟悉，更多的从业务出发去思考。最后贴一张图

娃刚出生，比较忙，以后有机会哈

很优秀，向飞哥学习

我的开源仓库的思考和设计可以看这里。https://bugvanisher.cn/categories/#%E6%85%A2%E6%9F%A5%E8%AF%A2%E5%88%86%E6%9E%90%E7%B3%BB%E7%BB%9F

你只需要依赖你测试的接口的接口描述，不需要管它的依赖吧。另外建议把这些描述类文件都放到一个公共仓库统一管理

有新增接口，更新下接口描述和 PB，就可以写新接口的测试啦

我理解有两种方式：
1、自己实现 GRPC client，这种需要自己根据 ip:port 调用 dial 连接这些方法，然后构造请求对象去调用具体的 grpc 方法，这种方式比较通用。可以参考：https://github.com/myzhan/boomer/blob/master/examples/grpc/main.go
2、看看自己项目其他应用是如何调用被测应用的 grpc 接口的，比如我们项目是使用 microkit 的，它的 rpc 接口通过 pb 定义，并生成.pb.go,.microkit.go 文件，里面就有 NewClient 方法，拿到 client 后直接用来发起请求就可以了。

client := livetech.NewClient()
req := &livetech.GetQualityListRequest{
}
resp, err := client.GetQualityList(context.Background(), req)

.pb.go,.microkit.go 文件 可以理解成是 rpc 服务的接口说明，用就是了。

最好能把 worker(slave) 那边的图贴出来，你是运行 go 版本的吧，默认是找本地 5557 端口的 master，你可以看看端口情况

感谢分享

今年以来我也开始担任面试官了，你这种循序渐进，开放式的面试方式很棒，学习到了，感谢分享~

感觉真的好奇妙啊，我们对这个问题的解决思路竟然如此的相似，两年前我做的一个开源项目就是用这个思路，一直没推广，换公司后用 go 比较多了，已经好久没更新了。 https://github.com/bugVanisher/no-slow-query

哈哈哈

webrtc 性能测试可以参考下面两篇文章，如果你的业务可以直接在 pc 浏览器上发起会话（或者包一层 web sdk），那还是比较容易做的。
https://www.cnblogs.com/chenkx6/p/13639629.html
https://blog.piasy.com/2020/03/28/KITE/index.html

我所在的 webrtc 业务有 web、安卓、iOS sdk，最近我使用 web sdk 模拟多房间在线会话，为压力测试提供了可能，不过相当耗费资源

哈哈，我将持续更新，欢迎交流探讨

不知不觉我工作也六年半了 ，时间好快，加油加油

麻烦看完我的系列文章，相信你会有自己的答案

不好意思，最近没怎么上来。
对于你的问题，连接池在纯产生压力的场景确实是没什么必要的，因为压力机就是为了在最短的时间产生最多的请求，这个在多协程共用单连接的时候达到顶峰。连接池的使用场景是在低频的请求序列时保持连接，减少反复连接 - 断开的开销。是的，文章里我应该说明一下，真实的场景是内部应用之间维护连接池，而不会只创建一个连接，使用连接池是因为我想保持跟 grpc 框架一致。这里我有一个问题，你是怎么理解并发用户数和连接数之间的关系的？在 http 和 grpc 的场景下，应该是不一样的

你是看到 history 有多个请求吧？这种情况一般是客户端有超时重试机制，一旦重试了，burp suite 再释放它已经没用了，因为客户端已经丢弃。

用得顺手都是好工具

嗯嗯，分布式模式下每个 slave（worker）都是独立的，如果你的文件是一样的那就会重复。文件中的数据是否一样，取决于你的需求场景啊，如果必须保证全局唯一，方法是有很多的，我提供一个比较『骚』的思路：
整体思想就是每个 slave 在压测前去获取一批全局唯一的数据
1、利用 init 事件钩子在 master 注册一个新的 API，负责分发唯一数据。
2、同样利用钩子在 slave 压测前去 master 获取并初始化全局唯一数据，然后压测。

纯 Python 压测会給自己带来很多麻烦，不建议在实际业务中这么做哈，接下来的两篇文章感觉是给我自己挖坑了 ，我尽量写出点干货吧，哈哈

我的博客分了几篇来写，这里我做了整合，没有必要一篇篇来了，一次看个过瘾吧，，

社区的第一篇文章，除了有点长，还是有诚意的。。。

哈哈，感觉是挖了个坑給自己