【BeetleX重构】gpRPC组件性能测试
内容提要
gpRPC是基于BeetleX新版本开发的RPC通讯组件，使用Google Protobuf的功能。它实现了高性能和使用方便的PRC组件，希望在32核的云主机上达到百万级别的吞吐能力。组件需要使用proto文件来描述消息定义，并实现相关接口和添加属性标记。服务端实现的类需要使用RpcService标记，客户端使用RpcClient对象创建接口实例进行服务调用处理。性能测试结果显示，20连接2000并发的量延时较高，需要调整组件的内部机制来优化性能。
延伸解读
gpRPC 与 gRPC 的定位差异
gpRPC 并非要替代 gRPC，而是基于 BeetleX 高吞吐复用特性构建的 RPC 组件，同样使用 Google Protobuf 描述消息。其核心目标是兼顾高性能与易用性，通过接口代理方式简化调用，并期望在 32 核云主机上达到百万级 RPS。与 gRPC 相比，gpRPC 更强调在 BeetleX 生态内实现高吞吐和便捷的接口代理操作。
消息定义与请求响应匹配机制
使用 gpRPC 时，除了用 proto 文件定义消息，每个消息类还需实现 IIdentifier 接口并添加 ProtocolObject 属性标记。IIdentifier 用于维护单连接复用下的请求与响应匹配关系，ProtocolObject 则通过 uint 值标识类型，供组件匹配具体对象。服务端实现类需标记 RpcService，客户端通过 RpcClient 创建接口实例进行调用。
性能测试暴露的 IO 合并问题
在 32 核云主机上，20 连接 2000 并发的测试显示 RPS 达到 110 万，但发送 IO 高达 80 万，导致延时较高。这表明消息合并利用率不足，批量 IO 优化空间较大。作者指出，若能将发送 IO 利用率提升至与接收 IO 相当的水平，吞吐量不变的情况下 CPU 使用率会大幅下降，因此需要调整组件内部机制。
优化方向与预期目标
针对测试中暴露的批量 IO 利用率不高的问题，作者计划调整 gpRPC 内部机制以优化 IO 合并。预期优化后，处理 100 万 RPS 的远程接口调用仅需约 50% 的 CPU。这一目标若达成，将显著降低高吞吐场景下的资源消耗，使 gpRPC 在 32 核云主机上更接近百万级吞吐的设计初衷。
Q&A
gpRPC组件的主要目标是什么？
gpRPC组件的主要目标是实现高性能和使用方便的RPC组件，期望在32核云主机上达到百万级别的吞吐能力。
如何使用proto文件定义消息？
gpRPC组件使用proto文件来描述消息定义，可以借助Grpc.Tools组件在VS中方便处理描述文件。
性能测试的结果如何？
性能测试显示20连接2000并发的量延时较高，虽然RPS达到了110W，但发送IO达到80万，需优化内部机制。
服务端如何实现gpRPC？
服务端通过gpRPC的RpcServer对象加载和启动服务，注册消息并设置监听端口。
客户端如何调用gpRPC服务？
客户端通过gpRPC的RpcClient对象创建接口实例进行服务调用，支持线程安全的重复调用。
gpRPC中如何维护请求响应匹配关系？
每个类需实现IIdentifier接口并添加ProtocolObject属性标记，以维护请求响应匹配关系。
