如何解决nodejs + grpc-node服务器比REST慢得多 使用grpc-node的服务B 使用Go gRPC的服务B 服务B与REST一起使用Koa 网络IO
我已经实现了2个服务A和B，其中A可以通过gRPC（使用带有Mali的grpc-node）和纯HTTP REST调用与B通讯。
请求大小可以忽略不计。
响应大小为1000个，如下所示：
{
"productId": "product-0","description": "some-text","price": {
"currency": "GBP","value": "12.99"
},"createdAt": "2020-07-12T18:03:46.443Z"
}
A和B都作为服务部署在GKE中，并且它们使用kube-proxy通过内部网络进行通信。
我发现REST版本比gRPC快很多。 REST调用的p99位于
详细信息
节点版本和操作系统：node:14.7.0-alpine3.12
依赖项：
"google-protobuf": "^3.12.4","grpc": "^1.24.3","mali": "^0.21.0",我什至通过设置gRPC选项grpc.use_local_subchannel_pool=1来创建客户端TCP池，但这似乎无济于事。
问题似乎出在服务器端，正如我从日志中看到的那样，grpc lib的call.startBatch调用花费了几秒钟来发送大小约为51kb的数据。这比REST版本要慢。
我还检查了服务的CPU和网络是否正常。 REST版本可以发送> 2mbps，而gRPC版本只能管理约150kbps。
在服务B（在gRPC中）上运行netstat会显示许多已建立的TCP连接（由于TCP池，这是预期的）。
我怀疑grpc核心C ++代码在某种程度上不如REST最佳，但我没有证据。
我接下来要看的任何想法？谢谢您的帮助
更新1
以下是一些基准：
设置
Blazemeter --REST--> services A --gRPC/REST--> service B
- 请求正文（两个滞后）可以忽略不计
-
service A是节点服务+ Koa -
service B有3个选项：-
grpc-node：具有grpc-node的节点 -
gRPC + Go：执行同一gRPC服务 -
REST + Koa：带有Koa的节点
-
-
Blazemeter --> service A：响应有效载荷可以忽略不计，所有测试都相同 -
serivce A --> service B：gRPC / REST响应有效载荷是ProductPrice中的1000：
message ProductPrice {
string product_id = 1; // Hard coded to "product-x",x in [0 ... 999]
string description = 2; // Hard coded to random string,length = 10
Money price = 3;
google.protobuf.Timestamp created_at = 4; // Hard coded
}
message Money {
Currency currency = 1; // Hard coded to GBP
string value = 2; // Hard coded to "12.99"
}
enum Currency {
CURRENCY_UNKNOWN = 0;
GBP = 1;
}
服务已部署到GCP中的Kubernetes，
- 实例类型：
n1-highcpu-4 - 每个服务5个豆荚
- 2个CPU，每个吊舱1 GB内存
- 使用群集IP的kube-proxy（不通过Internet）（我也用
clusterIP: None进行了无头测试，得出了相似的结果）
加载
50rps
结果
使用grpc-node的服务B
使用Go gRPC的服务B
服务B与REST一起使用Koa
网络IO
观察
-
gRPC + Go与REST大致相当（我认为gRPC会更快） -
grpc-node比REST慢4倍 - 网络不是瓶颈
解决方法
暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！
如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com(将#修改为@）