Are you implementing a server for streaming reply? I have provided you an implementation how to implement 'CallStreamDataReply' otherwise you won't be able to use asynchronous mechanism by grpc c++ server. Also, try to use c++ threads pool instead of grpc threads pool for cq.
I have written an end to end test for pubsub services to test how asynchronous server works. There is no serious problems in my tests. On Wed, May 22, 2019 at 2:50 AM Lalit Kumar <[email protected]> wrote: > Just to add I'm trying server streaming using c++ bindings. Client opens > just one long lived RPC and Server starts streaming data to client. Both > running on same Debian machine having 4 cores. Server is implemented using > async api. I'm getting max 23-25K messages/second. Message payload is just > 4 bytes. Tried multiple threads to service completionQ but its not > changing anything. > > -Lalit > > On Tuesday, May 21, 2019 at 10:38:15 AM UTC-7, Arthur Wang wrote: >> >> And, I've compiled the released versions for all the dependencies and the >> application itself. Results are basically the same. >> >> On Sun, May 19, 2019 at 5:19 PM Arthur Wang <[email protected]> wrote: >> >>> And, both the client and the server on the same machine, communicating >>> with tcp, even though I don't think this could be a reason for poor >>> throughput. >>> >>> On Sun, May 19, 2019 at 5:12 PM Arthur Wang <[email protected]> wrote: >>> >>>> And, of course, the cpu are not fully running on both win(~30+%, 100% >>>> fully load) and mac(200+%,800% fully load ). >>>> >>>> On Sun, May 19, 2019 at 5:08 PM Arthur Wang <[email protected]> wrote: >>>> >>>>> Hi all: >>>>> >>>>> I've done a benchmark for the asynchronous version of the c++ >>>>> server, but the result is terribly poor compared to either the official >>>>> one >>>>> <https://performance-dot-grpc-testing.appspot.com/explore?dashboard=5685265389584384> >>>>> or >>>>> some other results like this >>>>> <https://github.com/grpc/grpc/issues/6504> done by other users, I'm >>>>> wondering what is wrong with my test, could someone do me a favor? >>>>> >>>>> There are the details for my test.: >>>>> >>>>> Enrivonment : >>>>> >>>>> - win 10pro 64bit : intel i7 4.0GHZ * 4 physical core * 2 logic >>>>> core RAM:16GB >>>>> - mac high serria 10.13.6: intel i7 2.2GHZ * 4 physical core * 2 >>>>> logic core RAM:16G >>>>> >>>>> *Note: I don't have any linux machines, so there are no >>>>> results for it.* >>>>> >>>>> Grpc version: >>>>> >>>>> - win : 77ec6c94ad58bedfdf8f28682914e9893e318be0, around 2018.1 >>>>> - mac: e3f37b7f4320f0e016a806796e2adaed03bf23f7, around 2019.2 >>>>> >>>>> Compiler: >>>>> >>>>> - win: vs2015 Microsoft (R) C/C++ Optimizing Compiler Version >>>>> 19.00.24215.1 for x86 >>>>> - mac: Apple LLVM version 10.0.0 (clang-1000.10.44.4) >>>>> >>>>> Parameters: >>>>> >>>>> - number of CQs an server instance has. >>>>> - number of threads totally exist, evenly distributed on each CQ. >>>>> - number of pool size(which is the *CallData* instances >>>>> pre-allocated for each CQ. >>>>> >>>>> Client & Server Behavior: >>>>> >>>>> - Client: Sending arond 30-50k requests to the async server in >>>>> parallel, and waiting for all of them to be responded. >>>>> - Server: Based on the *greeter_async_server.cc of the helloworld >>>>> example* - just do some basically ignorable logic and response >>>>> immediately after that. >>>>> >>>>> * The code are in the attachments.* >>>>> >>>>> The result (requests the server can deal per second in average) is >>>>> : >>>>> >>>>> OS pool 1 thread 2 thread 4 thread 8 thread 16 thread >>>>> 1 CQ win 100 3647 4016 3366 3012 3427 >>>>> 200 3963 5202 3308 3411 4507 >>>>> 400 3787 4494 3476 3203 3123 >>>>> mac 100 38880 35803 22629 22128 22321 >>>>> 200 37778 35285 24801 21805 22172 >>>>> 400 39200 36231 23446 22311 22553 >>>>> 2 CQ win 100 3086 4144 4575 3662 3959 >>>>> 200 3334 4354 3588 3507 3536 >>>>> 400 3069 4299 3565 3830 3852 >>>>> mac 100 39154 32362 31948 25227 23441 >>>>> 200 37792 33046 31908 25169 24142 >>>>> 400 40584 33909 32446 25284 24943 >>>>> 4 CQ win 100 3204 4199 4644 3988 3742 >>>>> 200 3125 4097 3954 3997 3638 >>>>> 400 3207 4196 3731 4008 3526 >>>>> mac 100 39793 33101 28851 32310 25214 >>>>> 200 38804 31545 32605 32268 24869 >>>>> 400 38819 32776 31786 32133 25207 >>>>> >>>>> [image: image.png] >>>>> >>>>> Recap of the result: >>>>> >>>>> - number of CQs basically has nothing to do with the throughput, *which >>>>> is unbelievable, in my understanding, it is an critical factor after >>>>> learned how the polling-engine >>>>> >>>>> <https://github.com/grpc/grpc/blob/master/doc/core/epoll-polling-engine.md> >>>>> works.* >>>>> - number of pool size has nothing to do with the throughput,* I'm >>>>> not sure whether this is normal or not.* >>>>> - number of threads which are evenly distributed among the CQs *has >>>>> nothing to do with the throughput on windows, but decreasing it on mac. >>>>> This is somewhere wired.* >>>>> >>>>> Besides, I tested the synchronous version(*greeter_server.cc*) >>>>> of c++ server, giving me the result of 18807 on mac and 3041 on win, which >>>>> is also very poor. >>>>> >>>>> I've read the example of *grpc\test\cpp\qps\server_async.cc *which >>>>> said to be an good example of how to write a high throughput async c++ >>>>> server. I found its approach of enhancing the throughput is more of less >>>>> the same with mine: >>>>> >>>>> - scale #CQ. >>>>> - scale #thread. >>>>> >>>>> I haven't test the *qps example* on my machine, I haven't find a >>>>> easier way to build it and hard to believe to it can achieve a better >>>>> result with the same environment of mine. >>>>> >>>>> I know there are something must be wrong, but where are they? >>>>> >>>>> - Thanks a lot. >>>>> - 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/0bb9c0de-e91e-42ce-b99f-9ace2b44d5b7%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/0bb9c0de-e91e-42ce-b99f-9ace2b44d5b7%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAF84%3Dte6MSY6vuBJsYEJtVOtoDCPDGzfarn1tdjFa%2B_2mreqDA%40mail.gmail.com.
