Let's say I have 2 functions add and subtract on the server. Can I use bidirectional stream in this scenario to increase throughput? If so, do I have to have an identifier for each request and response to distinguish between the responses(like reqId) at the client? Normally, they will be unary calls but want to increase throughput by streaming.
2 Answers
It is true that streaming messages have lower overhead than unary RPCs. Although the gRPC team tends to discourage using streams just for this performance gain unless it is actually necessary, as the messages can't be distributed onto multiple backends, multiple threads on one backend, and it is more complicated and harder to debug. Although if you are considering doing batching with unary RPCs, then streaming do have advantages you may prefer.
If the server computes responses in the order the requests were received, then you don't need a reqId; the 1st response would be for the 1st request, 2nd for 2nd, 3rd for 3rd, etc. gRPC streams preserve message order.
Using a bidirectional stream for higher throughput would be a bad idea.
For lower concurrent requests, both have comparable latencies. However, for higher loads, unary calls are much more performant.
Streams ensure that messages are delivered in the order that they were sent, this would mean that if there are concurrent messages, there will be some kind of bottleneck.
There is no apparent reason we should prefer streams over unary, given using streams comes with additional problems like :
- Poor latency when we have concurrent price requests
- Complex implementation at the application level
- Lack of load balancing: the client will connect with one server and ignore any new servers
A detailed analysis with some benchmarks here : https://nshnt.medium.com/using-grpc-streams-for-unary-calls-cd64a1638c8a
Related