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. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/815dcbba-155e-4775-9553-2056b8ce599a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
