RPC 框架 Kitex 实践入门：性能测试指南

一些压测项目通常会把 Client 和 Server 进程混部进行压测，然后得出整个框架的性能数据，这其实和线上实际运行情况很可能是不符的。

如果要压测 Server，应该给 Client 尽可能多的资源，把 Server 压到极限，反之亦然。如果 Client 和 Server 都只给了 4 核 CPU 进行压测，会导致开发者无法判断最终得出来的性能数据是哪个视角下的，更无法给线上服务做实际的参考。

对齐连接模型

常规 RPC 的连接模型主要有三种：

• 短连接：每次请求都创建新连接，得到返回后立即关闭连接

• 长连接池：单个连接同时只能处理一次完整请求与返回

• 连接多路复用：单个连接可以同时异步处理多个请求与返回

每类连接模型没有绝对好坏，取决于实际使用场景。连接多路复用虽然一般来说性能相对最好，但应用上必须依赖协议能够支持包序列号，且一些老框架服务可能也并不支持多路复用的方式调用。

Kitex 最早为保证最大程度的兼容性，在 Client 端默认使用了短连接，而其他主流开源框架默认使用连接多路复用，这导致一些用户在使用默认配置压测时，出现了比较大的性能数据偏差。

后来为了契合开源用户的常规使用场景，Kitex 在 v0.0.2 中也加入了默认使用长连接的设置。

对齐序列化方式

对于 RPC 框架来说，不考虑服务治理的话，计算开销主要都集中在序列化与反序列化中。

Kitex 对于 Protobuf 的序列化使用的是官方的 Proto