Hi everyone, I just implemented a cpp interface for my software using synchronous gRPC API. Both clients and server will run locally.
I have multiple services with different kind of rpc : - simple RPC to get/set value (fast computation time) - server side streaming RPC to subscribe to continuous data informations The server side rpc are "infinite" as the server sends data at a given frequency until the client disconnects. To not only have this kind of request in my thread pool and block simple rpc requests, I set a maximum client number for each streaming rpc. Finally, I set the number of thread in my thread pool in order to have at least one thread for each request if I have : - as many requests as the maximum number of clients for each streaming rpc - 2 requests for each simple rpc. Exemple : Let's consider a server with only one service containing 1 server side streaming rpc and 2 simple rpc. The maximum client number for the streaming rpc is 3. I will set my thread pool to 3 + 2 * 2 = 7 threads. In normal use case I will have 2-3 clients maximum for each rpc but as I have a total of 18 simple rpc and 5 server side streaming rpc I can have a thread pool between approximately 50 and 70 threads. If my interface evolves I fear that I will have too many threads in my thread pool. Do you think about other limitations I could have using the synchronous API ? Do you think it is inevitable to move to the async API for this kind of interface ? Looking forward to your feedback! Théo -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/75d71b30-a009-452b-a782-d5d133d85b5bn%40googlegroups.com.
