Splitting hairs a little the EventLoop is actually an EventLoopGroup, which 
is a collection of threads dedicated to handling network traffic.   Since 
networks are usually very fast, much faster than the CPU can send, it's 
okay to just have a few threads.   (a theoretical ideal being the same as 
the number of cores).

Some processing does  occur in the event loop, such as SSL encoding, but 
this is usually not a bottleneck.  In the Async Client, there is a closed 
loop on each RPC, meaning that as soon as one completes, the next one 
starts.  This bounds the number of active RPCs at any time, so the event 
loops are not overloaded.


ForkJoinPool is used because it's queues are sharded and do not have 
contention.   ForkJoinPool is highly parallel, and implements work stealing 
to keep all threads active.  Compare this to ThreadPoolExecutor, which has 
a single blocking queue.   If you have 32 threads all fighting over the 
queue, it slows down a lot.  (The QPS tripled when I switched us over to 
it!).

Carl
  

On Tuesday, January 23, 2018 at 5:45:41 PM UTC-8, Anjaneya Srujan 
Narkedamalli wrote:
>
> In QPS benchmarks AsyncClient.java, a shared executor(ClientExecutor is 
> instantiated once and reused) is used but a new EventLoop is used for every 
> Channel. is this the preferred config?
>
> What are the considerations for whether using a shared eventloop or not?
>
> Also, in the QPS benchmark is there any specific reason to use a 
> ForkJoinThreadPool for client Executor over FixedThreadPool (I could not 
> notice any ForkJoinTask's being executed, correct me if I am wrong)?
>

-- 
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 post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/99c8ce35-f698-4f4b-82ab-dacc8d6e58fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to