terrymanu commented on issue #37569:
URL:
https://github.com/apache/shardingsphere/issues/37569#issuecomment-3696825223
The Proxy doesn’t split or create client threads. Performance gain comes
from routing by sharding key to different nodes, where each node executes
independently, reducing single-node resource contention.
Connection pool sizing is per data source (node); active connections
depend on routing and concurrency, not a fixed “all threads per node.”
- Client threads: remain 6 (or 200 for sysbench); the Proxy only
routes/forwards, it doesn’t split threads.
- Routing & parallelism: for sharded writes, each SQL goes to one
shard/node based on the sharding key. With even distribution, two nodes each
handle roughly half the requests, reducing lock/CPU/IO contention per node, so
throughput rises. The lift isn’t from doubling thread count but from splitting
work across independent resource pools.
- Proxy/backend connections: Hikari pool config applies per data source;
two nodes each have up to 200 connections, actual usage depends on active
requests routed there. Sysbench’s 200 concurrency roughly splits under even
sharding; it’s not “each node must have 200 active threads.”
- Near-2× gain requires: balanced sharding-key distribution, sufficient
front-end concurrency, adequate node resources, and no other bottlenecks
(cross-shard/broadcast SQL will reduce gains).
--
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]
