[
https://issues.apache.org/jira/browse/CASSJAVA-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18137580#comment-18137580
]
Jeff Shaw commented on CASSJAVA-145:
------------------------------------
I created a downstream issue and PR for Scylla.
https://github.com/scylladb/java-driver/issues/1362
https://github.com/scylladb/java-driver/pull/1361
> Reduce CPU cost of DefaultLoadBalancingPolicy query plans
> ---------------------------------------------------------
>
> Key: CASSJAVA-145
> URL: https://issues.apache.org/jira/browse/CASSJAVA-145
> Project: Apache Cassandra Java driver
> Issue Type: Improvement
> Reporter: Jeff Shaw
> Assignee: Jeff Shaw
> Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have an application that I need to run insert queries as efficiently as
> possible. Using a Java Flight Recorder profile of the Scylla client version
> 4.17.0, I found that DefaultLoadBalancingPolicy.newQueryPlan() used 38% of
> the CPU time. This ticket aims to reduce that without changing the query plan
> order. The Scylla client uses the Cassandra client as an upstream library, so
> I want to do as much work as possible here first.
> The first optimization I found is to avoid ArrayUtils.rotate()'s O(n^2)
> implementation, where n is the number of live nodes in the local data center.
> The way I think this could be done efficiently is to instead introduce a new
> class that provides elements in the rotated order as they are requested. This
> makes the worst case O( n ), but many cases won't need to produce all n
> values.
> A second optimization is to rewrite ArrayUtils.bubbleDown() and bubbleUp()
> using System.arraycopy().
> A third optimization in newQueryPlan() is to exit the replica scan once all
> replicas are found.
> Optionally, I thought maybe a good optimization would be to reorder the
> method calls in isUnhealthy() to call isResponseRateInsufficient() first.
> With that change, some calls to getInFlight() will be skipped.
> Following are benchmark results for when a busy node has a sufficient
> response rate in 4.x and then after a draft implementation for this ticket.
>
> ||node count||before (ns)||after (ns)||
> |3|82|71|
> |10|176|115|
> |20|483|134|
> |50|2460|197|
> For 3 nodes, reordering isUnhealthy() causes some regressions when nodes
> aren't busy: from 59 to 86 ns with an insufficient response rate, and from 57
> to 73 ns with a sufficient one.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
