这是 gRPC 中双向流式 RPC 的意图吗？
Is this an intention of bidirectional streaming RPC in gRPC?
我在我的 gRPC 客户端上执行一元 RPC 时，我的 CPU 已达到极限。我想知道尝试用基本持续整个应用程序生命周期的双向流式 RPC（或它们的集合？）替换一元 RPC 是否有意义？我不知道双向流式 RPC 是否适用于像这样的标准 1 request/1 响应通信。动机是避免创建新的 TCP 连接。
I can't tell if bidirectional streaming RPC is intended for standard 1 request/1 response communication
如果您要使用请求-回复消息模式，只需使用一元请求-回复 (RPC)。它专为该模式和语义而设计，例如重试是众所周知的。
The motivation would be to avoid creating new TCP connections.
gRPC 使用 HTTP/2，因此所有一元 RPC 请求已经使用相同的 TCP 连接 - 因为 HTTP/2 通过相同的 TCP 连接多路复用所有请求。
I am maxing out my CPU on my gRPC client doing unary RPC.
这听起来有点罕见。你能改变你的沟通模式吗？在等待响应之前流式传输多个请求？替代批处理数据并很少发送更大的请求？或者您能否详细说明您的消息模式？
正如@Jonas 所建议的那样，仅仅为了更高的吞吐量而使用双向流并不是一个好主意。
Google 的 gRPC 团队反对它，但尽管如此，似乎很少有人认为从理论上讲，流应该有更低的开销。但这似乎不是真的。
可能是因为流确保消息按发送顺序传递，因此在有并发消息时会造成某种瓶颈。
对于较低的并发请求，两者都有可比的延迟。但是，对于更高的负载，一元调用的性能要高得多。
这里有详细分析：https://nshnt.medium.com/using-grpc-streams-for-unary-calls-cd64a1638c8a.
我在我的 gRPC 客户端上执行一元 RPC 时，我的 CPU 已达到极限。我想知道尝试用基本持续整个应用程序生命周期的双向流式 RPC（或它们的集合？）替换一元 RPC 是否有意义？我不知道双向流式 RPC 是否适用于像这样的标准 1 request/1 响应通信。动机是避免创建新的 TCP 连接。
I can't tell if bidirectional streaming RPC is intended for standard 1 request/1 response communication
如果您要使用请求-回复消息模式，只需使用一元请求-回复 (RPC)。它专为该模式和语义而设计，例如重试是众所周知的。
The motivation would be to avoid creating new TCP connections.
gRPC 使用 HTTP/2，因此所有一元 RPC 请求已经使用相同的 TCP 连接 - 因为 HTTP/2 通过相同的 TCP 连接多路复用所有请求。
I am maxing out my CPU on my gRPC client doing unary RPC.
这听起来有点罕见。你能改变你的沟通模式吗？在等待响应之前流式传输多个请求？替代批处理数据并很少发送更大的请求？或者您能否详细说明您的消息模式？
正如@Jonas 所建议的那样，仅仅为了更高的吞吐量而使用双向流并不是一个好主意。
Google 的 gRPC 团队反对它，但尽管如此，似乎很少有人认为从理论上讲，流应该有更低的开销。但这似乎不是真的。
可能是因为流确保消息按发送顺序传递，因此在有并发消息时会造成某种瓶颈。
对于较低的并发请求，两者都有可比的延迟。但是，对于更高的负载，一元调用的性能要高得多。
这里有详细分析：https://nshnt.medium.com/using-grpc-streams-for-unary-calls-cd64a1638c8a.