再加加看

纯 python 不太适合做压测，GIL 的存在导致你只能 fork 进程，虽然说现在 asyncio+uvloop 这一套效率直逼 go，但是也只是单进程，多进程的话本身 pick 也是有开销的，不过可以试试看看。对于 c++ 实现的压测工具来说，500/s 小 case，1w/s 消息处理都不算高

再创未来

pb 接口的话是 google 官方给的,json 的话明显效率上是不够的，越多机器人，效率越低下，一般是函数注册，locust 你还需要自己去改 socket 保持长连接，压测可不是只看高并发的时候，往往很多业务逻辑需要跑一段时间才能发现问题

但是协议压测还是挺大不同，协议测试、压测需要保持长连接，协议需要关注边界、业务逻辑，压测需要关注响应时间、cpu 占用等等，这里对 protobuf 的处理是类似，对压测来说，需要根据回调去处理对应 case，协议测试则不太需要关注这一点

protobuf 自带 json 转换的

这样做也不影响

我们的做法加了一个输入框，截取的时候 copy 了一份 buffer 到处理队列，然后直接转发，修改消息的话在处理队列处理就好了，进入处理队列后明文出来，复制明文填入输入框，输入就可以了

是

确认一下文件是不是最新，看堆栈就是找不到了，可以 debug 调试一下看看为什么找不到

instance 回来的是 bool 值哦，create 的时候需要引入 proto 的类型，createPB("log_pb2.logTag")

google 已经提供了接口去做这件事情

python 用的少了，现在都用 c++

FindMessageTypeByName(msgName)

构造方法里面调用 addModule,会把你的 pb 对象都加载到内存，有两个方法写错了，外网没有 pb，不能 debug，python 的 ide 不是强类型检查，自动补全没仔细看，所以写错了，不好意思哈，代码看下面

是的

extern "C"

c++,可以拓展 cpython

看一下官方文档，我们是用 c++ 的 api 做的，python 部分只是传参数，c++ 去处理

可以看下官方文档，google.protobuf.json_format 可以解决你遇到的问题，ParseDict(buffer, msg), MessageToDict(msg)

协议、压测、配置
检查配置，确保配置不出问题
协议的话覆盖功能测不到的点
压测就看性能、并发了

反射或者 eval()

直接用 so 就好了，全都封装好，调用就可以了，不是更简单吗