[
https://issues.apache.org/jira/browse/CASSANDRA-21637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18112093#comment-18112093
]
Dmitry Konstantinov edited comment on CASSANDRA-21637 at 9/6/26 4:38 PM:
-------------------------------------------------------------------------
e2e select 10-row partition test using BTI SSTables, 1 node (using trunk +
CASSANDRA-21354 as baseline) - we have about 6% improvement in e2e throughput:
{code:java}
-----------------------------------------------------------------------
metric Before After delta
-----------------------------------------------------------------------
Op rate 318,737 op/s 338,474 op/s +6.2%
Partition rate 267,269 pk/s 283,823 pk/s +6.2%
Row rate 2,672,685 row/s 2,838,232 row/s +6.2%
Latency mean 1.5 ms 1.5 ms +0.0%
Latency median 1.4 ms 1.3 ms -7.1%
Latency 95th percentile 2.9 ms 2.6 ms -10.3%
Latency 99th percentile 5.5 ms 4.4 ms -20.0%
Total partitions 12,577,859 12,578,059
Total errors 0 0
Total GC count 13 12 -7.7%
Total GC memory 239.890 GiB 221.437 GiB -7.7%
{code}
CPU profiles before vs after:
* [^noser_base_btiNoDoubleReadBefore_cpu.html]
* [^noser_base_btiNoDoubleReadAfter_cpu.html]
After the change we see only 1 place with chunk loading, lz4 and CRC32
computation vs 2 before
!image-2026-09-06-17-35-44-923.png|width=600!
was (Author: dnk):
e2e select 10-row partition test using BTI SSTables, 1 node (using trunk +
CASSANDRA-21354 as baseline) - we have about 6% improvement in e2e throughput:
{code:java}
----------------------------------------
metric Before After delta
-----------------------------------------------------------------------
Op rate 318,737 op/s 338,474 op/s +6.2%
Partition rate 267,269 pk/s 283,823 pk/s +6.2%
Row rate 2,672,685 row/s 2,838,232 row/s +6.2%
Latency mean 1.5 ms 1.5 ms +0.0%
Latency median 1.4 ms 1.3 ms -7.1%
Latency 95th percentile 2.9 ms 2.6 ms -10.3%
Latency 99th percentile 5.5 ms 4.4 ms -20.0%
Total partitions 12,577,859 12,578,059
Total errors 0 0
Total GC count 13 12 -7.7%
Total GC memory 239.890 GiB 221.437 GiB -7.7%
{code}
CPU profiles before vs after:
* [^noser_base_btiNoDoubleReadBefore_cpu.html]
* [^noser_base_btiNoDoubleReadAfter_cpu.html]
After the change we see only 1 place with chunk loading, lz4 and CRC32
computation vs 2 before
!image-2026-09-06-17-35-44-923.png|width=600!
> Avoid double chunk read for BTI small partitions during a select query
> execution
> --------------------------------------------------------------------------------
>
> Key: CASSANDRA-21637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21637
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
> Reporter: Dmitry Konstantinov
> Assignee: Dmitry Konstantinov
> Priority: Normal
> Fix For: 6.0.x, 7.x
>
> Attachments: image-2026-09-02-15-59-03-586.png,
> image-2026-09-06-17-35-44-923.png, noser_base_btiNoDoubleReadAfter_cpu.html,
> noser_base_btiNoDoubleReadBefore_cpu.html
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> BtiTableReader.getExactPosition() opens a data-file reader to verify the
> partition key when the trie payload is negative (means the partition small
> enough to have no row index entry). It then closed that reader, and
> AbstractSSTableIterator immediately reopened the same file at the same
> position. So, we read the same chunk twice in such scenario as well as run
> LZ4 decompression and CRC32 check twice. We can re-use the reader to avoid it.
> !image-2026-09-02-15-59-03-586.png|width=600!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
