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/CAKymdqPx6_XLL5zr7nqAsCA_quuy3VCYfKA%3DpKBLCJd04KKr%3Dw%40mail.gmail.com.

Reply via email to