[
https://issues.apache.org/jira/browse/CASSANDRA-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17014713#comment-17014713
]
Jordan West edited comment on CASSANDRA-15213 at 1/13/20 10:55 PM:
-------------------------------------------------------------------
PEBKAC. I was rushing to run the bm between meetings and used the wrong branch.
I am able to reproduce your numbers:
{code}
[java] Benchmark Mode Cnt
Score Error Units
[java] LatencyTrackingBench.benchInsertToDEHR thrpt 5
39263498.481 ± 1809260.330 ops/s
[java] LatencyTrackingBench.benchLatencyMetricsWrite thrpt 5
10473724.356 ± 137670.100 ops/s
{code}
EDIT: I agree re: an improved benchmark but its encouraging we are seeing
improved performance and memory usage with the test we have and this branch.
was (Author: jrwest):
PEBKAC. I was rushing to run the bm between meetings and used the wrong branch.
I am able to reproduce your numbers:
{code}
[java] Benchmark Mode Cnt
Score Error Units
[java] LatencyTrackingBench.benchInsertToDEHR thrpt 5
39263498.481 ± 1809260.330 ops/s
[java] LatencyTrackingBench.benchLatencyMetricsWrite thrpt 5
10473724.356 ± 137670.100 ops/s
{code}
> DecayingEstimatedHistogramReservoir Inefficiencies
> --------------------------------------------------
>
> Key: CASSANDRA-15213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15213
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
> Reporter: Benedict Elliott Smith
> Assignee: Jordan West
> Priority: Normal
> Fix For: 4.0-beta
>
>
> * {{LongAdder}} introduced to trunk consumes 9MiB of heap without user
> schemas, and this will grow significantly under contention and user schemas
> with many tables. This is because {{LongAdder}} is a very heavy class
> designed for single contended values.
> ** This can likely be improved significantly, without significant loss of
> performance in the contended case, by simply increasing the size of our
> primitive backing array and providing multiple buckets, with each thread
> picking a bucket to increment, or simply multiple backing arrays. Probably a
> better way still to do this would be to introduce some competition detection
> to the update, much like {{LongAdder}} utilises, that increases the number of
> backing arrays under competition.
> ** To save memory this approach could partition the space into chunks that
> are likely to be updated together, so that we do not need to duplicate the
> entire array under competition.
> * Similarly, binary search is costly and a measurable cost as a share of the
> new networking work (without filtering it was > 10% of the CPU used overall).
> We can compute an approximation floor(log2 n / log2 1.2) extremely cheaply,
> to save the random memory access costs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
