using grpc c++‘s async server api, should i add one cq per rpc method or just one cq for all service?

[river]

using grpc c++‘s async server api, should i add one cq per rpc method or just one cq for all service?

I am taking over a grpc c++ service in my job. it use 10 completionqueue for a async service method , and yet another 20 completionqueue for another stream service method. The handling of the completionqueue is quite similar to the helloworld async service example, except that it use one thread worker per completionqueue.

Such a design is not very convenient for adding more service method. And I am thinking that refactoring it to using just one completionqueue, and dispatching the tags in the completionqueue to my own domain transactions handling thread pool. Is it a right disign pattern or is there any better?

[Vijay Pai]

You can use as many or as few CQs as you choose. Some of our examples use 1 CQ for the whole application, some use multiple CQs per server. Either way, the CQ is thread-safe. The tradeoff is a basic one of contention (more CQs means less lock contention in the CQ) vs work stranding (1 CQ means that any thread can pick up any piece of work, so less chance of having available threads while the system as a whole is idle). Generally speaking, we recommend 1 CQ unless there is a strong reason to use multiple.