[
https://issues.apache.org/jira/browse/HBASE-30321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18105661#comment-18105661
]
Charles Connell edited comment on HBASE-30321 at 8/18/26 5:20 PM:
------------------------------------------------------------------
This change has been tested on our load-testing infrastructure inside Hubspot.
For a workload of Gets that return small results, we saw a modest decrease in
allocation rate:
!gzip bytebuff alloc rate.png|width=500!
In some cases, we also saw an improvement in handler utilization, but this
effect was not always there:
!gzip bytebuff handler utilization.png|width=500!
Overall, the conclusion was that this change has no negative impact on
performance, and may have a positive impact. The positive impact comes from
some combination of:
- Avoiding a byte array allocation on each block being decompressed
- Avoiding unnecessary copies of the input data into a direct ByteBuffer and
then back into a byte array in order to use zlib
- Invoking zlib with the entire block's data at once, instead of invoking it
chunks, thus avoiding crossing the JNI boundary any more than necessary
was (Author: charlesconnell):
This change has been tested on our load-testing infrastructure inside Hubspot.
For a workload of Gets that return small results, we saw a modest decrease in
allocation rate:
!gzip bytebuff alloc rate.png!
In some cases, we also saw an improvement in handler utilization, but this
effect was not always there:
!gzip bytebuff handler utilization.png!
Overall, the conclusion was that this change has no negative impact on
performance, and may have a positive impact. The positive impact comes from
some combination of:
- Avoiding a byte array allocation on each block being decompressed
- Avoiding unnecessary copies of the input data into a direct ByteBuffer and
then back into a byte array in order to use zlib
- Invoking zlib with the entire block's data at once, instead of invoking it
chunks, thus avoiding crossing the JNI boundary any more than necessary
> Implement GzipByteBuffDecompressor with off-heap decompression path
> -------------------------------------------------------------------
>
> Key: HBASE-30321
> URL: https://issues.apache.org/jira/browse/HBASE-30321
> Project: HBase
> Issue Type: Improvement
> Reporter: Saad Ahmad Sabri
> Assignee: Saad Ahmad Sabri
> Priority: Major
> Attachments: gzip bytebuff alloc rate.png, gzip bytebuff handler
> utilization.png
>
>
> Add GzipByteBuffDecompressor, a ByteBuffDecompressor implementation that
> enables GZIP
> decompression directly from/to ByteBuffer objects without intermediate byte
> array copies.
> one decompression path is supported:
> - Off-heap (direct ByteBuffer): delegates to Hadoop's native
> ZlibDirectDecompressor with
> GZIP_FORMAT when native zlib is loaded
> Also adds GzipHFileDecompressionContext to carry per-block configuration, and
> input-length validation to reject inputs too short to be a valid GZIP member.
> The prior code had no ByteBuff-based GZIP decompression path, requiring byte
> array
> copies for on-heap scenarios. This eliminates those copies for both direct
> and heap
> buffer cases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
