Calling grpc server from multi-threaded client

Question

I have a client side code, which is multi-threaded, calling updateInfo rpc method to the grpc server to update the information(Eventually will updata data in SQL).

I think there are 2 ways to call the updateInfo rpc server from the client side:

1. Cache the updated data in to the memory of each client thread and then polling call the updateInfo rpc server which iterate the client side threads and update data from cache on each thread.
2. Each client thread call the updateInfo rpc server directly.

My question is:

1. Can the multi-threaded client side call the updateInfo rpc server the same time? If true, then the rpc server side will queue the request from the client side if the server cannot process quick enough?
2. Even if the rpc server side can handle multiple calls from the client side the same time, is there any advantage of using the 1st method, caching?

Answer 1

gRPC supports simultaneous requests on client-side and server-side, processing in different threads. This is the out-of-box experience. There can be a point where queuing occurs, but it is much higher than "more than one RPC".

So if each of your threads calls updateInfo, then they likely would be processed concurrently on server-side. Whether there is an advantage to the first or second option is more a question of your application architecture; option 1 performs some synchronization in the client which reduces the work the server would need to do. Which component do you want doing that work? Deciding between the two options is an application-level architectural optimization decision. (Optimization here is not just optimization CPU, but also code complexity, who is paying for resources, and scaling.) For many applications the decision probably doesn't matter at the scale involved, so option 2 is probably better as it is simpler to implement on the client and the same difficulty on the server.