Other than Cq, grpc creates some internal threads to handle some background work. I guess it is possible that what you observed is that some work is offloaded to the background executor.
On Friday, August 2, 2019 at 11:57:42 PM UTC-7, Arthur Wang wrote: > > Hi all: > > I know that the CompletionQueue is application threads driven, which > means that the requests entrusted on the CQ will be sent out on the wire > only > after there are some application threads polling on it. Before that, none > of the requests will be sent, here is a github question > <https://github.com/grpc/grpc/issues/14104> to consult to. > > But I found that if I entrust enough requests to a CQ ( ~50k), before > any threads start polling on it, the CQ has already sent some of them out > to the server! It seems that the #request has reached some threshold, > and CQ just can't hold the them so having to just let them go. > > Am I understanding this correctly? There is no problems with this > behavior for me except that bring troubles on benchmark : I don't know the > exact start point when the server start processing , and can't get an > accurate throughput data. > > language : c++ (for both client & server) > grpc version : v1.21.x > OS : win10 pro > compiler : vs2015 Microsoft (R) C/C++ Optimizing Compiler Version > 19.00.24215.1 for x86 > > > > - Regards > - Arthur > -- 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 grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/54d372ef-dad8-422a-ab36-70e23ca5d795%40googlegroups.com.
