Best practice for stream usage?

[Christoph John]

Hi,

we are about to create a service which receives subscription requests from various clients. Each client can subscribe to price updates for specific instruments.

The question we are facing now is whether it is better to have one rpc call which gets a set of instruments (say 1000) as input and continuously returns a stream of price updates for each of the 1000 instruments.

Or if it is better to have one rpc call per instrument which then returns price updates only for that specific instrument.

Background of the question is if there are certain limits that we might hit. I know there is the concurrent stream limit of 100 but IIRC this is changed after the handshake.

On the client side we are expecting to start price update requests for about 10.000 (probably less) instruments per client.

On the server side we are expecting about 100 clients. Maybe more.

On the server side we are using Java, on client side .NET and Java.

We are currently in the process of setting up some basic tests. In a *very* simple test I quickly started 1.000.000 rpc calls in a row which (after garbage collection) did not seem to have a noticeable effect on heap memory. Also the number of threads remained roughly the same.

Thanks in advance for any suggestions.

Cheers,

Chris.

[Benjamin Krämer]

Take it with a grain of salt since I'm not part of the gRPC team, but I will answer to the best of my understanding.

If you have multiple gRPC streaming RPCs on the same channel, it will all be multiplexed over the same connection. Using a non-streamed RPC per instrument has a bigger overhead.

You can have a look at the proto for GRPCLB created by one of the gRPC teams: https://github.com/grpc/grpc-proto/blob/master/grpc/lb/v1/load_balancer.proto

They will also create one streamed-RPC per load-balanced name and stream the results back. This should be pretty similar to what you have with your instruments (balanced servers) and price updates (DNS updates).