CRZbulabula commented on PR #1466:
URL: https://github.com/apache/ratis/pull/1466#issuecomment-4535184461
Thanks for the review. I have pushed commit 2088cdf7 addressing the comments:
- Moved NettyUtils to ratis-common as org.apache.ratis.util.NettyUtils and
removed the separate GrpcEventLoops helper.
- Added gRPC configs similar to NettyConfigKeys:
- raft.grpc.use-epoll
- raft.grpc.client.worker-group.size
- raft.grpc.server.worker-group.size
- raft.grpc.server.boss-group.size
- The worker-group.size defaults are now positive and CPU-based: Math.max(1,
NettyRuntime.availableProcessors() * 2).
- GrpcServicesImpl now creates one serverBosses group, one serverWorkers
group, and one clientWorkers group. The server builders share
serverBosses/serverWorkers, and all server-to-server clients share
clientWorkers.
- NettyUtils.shutdownGracefully(...) now starts shutdownGracefully() for all
groups first, then awaits termination.
- Verified with: mvn -pl ratis-grpc,ratis-netty,ratis-test -am -DskipTests
clean test-compile
For the performance question: I ran a manual MiniRaftClusterWithGrpc
benchmark on my macOS arm64 host with JDK 21, using 500 warmup ops and 5000
measured async sends at concurrency 16, with 3 iterations per config. Median
results for worker sizes 8/16/24/32 were about 290/285/291/313 ops/s, p50
53.4/56.0/54.3/49.8 ms, p99 75.6/75.4/71.2/77.0 ms, and 0 failures. This did
not show a regression from using bounded/configurable worker groups; the gRPC
worker group handles non-blocking I/O while request execution is still handled
by raft.grpc.server.async.request.thread.pool.size.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
