本地测试时gRPC发送360MB消息速度缓慢问题咨询

性能结果是否正常 #

你测试得到的6.8秒传输360MB消息的结果，在当前配置下属于正常情况：

• 折算下来单连接单调用的吞吐约为53MB/s，符合默认配置的Python gRPC处理超大单消息的性能预期
• grpcio 1.40.0属于较老版本，Python 3.6.8本身也存在较多性能劣化点，进一步拉低了大消息处理效率

本地传输开销过高原因 #

本地回环场景下的开销确实几乎都来自gRPC内部处理，而非网络传输，该overhead属于正常情况：

• gRPC默认面向小包高频的微服务调用场景优化，原生默认单消息大小限制仅为4MB，大消息场景下的帧分片、内存拷贝、缓冲区管理开销会指数级上升
• 即使你提前完成了业务层编码，gRPC发送时仍会对整个Protobuf消息做一次序列化，360MB级别的大对象在Python封装层会产生多次冗余内存拷贝，这部分开销占总耗时的90%以上
• 你当前将numpy数组编码为base64字符串的方案，会让数据体积额外膨胀33%，进一步加大了序列化和传输的负载

gRPC是否适合大消息传输 #

gRPC并非完全不能用于大消息传输场景，但单条普通RPC调用传超大消息的方案确实不是最优选择，你可以通过以下优化将耗时降低到亚秒级：

• 改用gRPC流式传输接口，将360MB的大消息拆分为1_{4MB大小的块分批发送，该改动可以将吞吐提升3}5倍
• 放弃base64编码，直接用Protobuf的bytes类型存储numpy数组的二进制内容，既可以减少33%的传输体积，也能省掉base64编解码开销
• 升级运行环境：Python升级到3.9+版本，grpcio升级到1.50+版本，仅版本升级就能带来至少20%的性能提升
• 调整gRPC运行参数：除了放开收发消息大小限制外，将grpc.http2.max_frame_size调整到16MB左右，减少帧分片开销，同时关闭不必要的代理检测配置

内容的提问来源于stack exchange，提问作者SciCompLover