FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

fix: update BlobReadSession ScatteringByteChannel projection to use less CPU by BenWhitehead · Pull Request #3324 · googleapis/java-storage · GitHub

fix: update BlobReadSession ScatteringByteChannel projection to use less CPU - #3324

Merged
BenWhitehead merged 2 commits into
mainfrom
fix/brs/less-cpu
Oct 6, 2025
Merged

fix: update BlobReadSession ScatteringByteChannel projection to use less CPU#3324
BenWhitehead merged 2 commits into
mainfrom
fix/brs/less-cpu

Conversation

BenWhitehead commented Oct 2, 2025
edited
Loading

Copy link
Copy Markdown
Collaborator

Switch to using a graceful poll of the queue rather than a spin loop poll.

Elements being added to the queue will happen asynchronously from a background gRPC thread. Rather than immediately returning if the queue is empty allow waiting up to 10 microseconds (possibly not optimal duration, but testing shows good results -- before ~51% of cpu time is spent in StreamingRead.read, after ~13% of cpu time is spent in StreamingRead.read for roughly the same wall time 1.59% before, 1.52% after). This also has the added benefit of reduced perceived latency for an application.

profiled workload results

Download 128MiB object from 0-EOF 1000 times, while async profiler is profiling event=cpu. Using StorageDataClient.fastOpenReadSession to begin the read while creating the session.

All values below are latency in milliseconds

p50 p90 p95
before ~ 266 ~ 408 ~ 468
after ~ 253 ~ 384 ~ 431
  • Remove no longer necessary Buffers.totalRemaining call

async-profilers flame graphs

cpu wall
before
after

…ess CPU

Switch to using a graceful poll of the queue rather than a spin loop poll.

Elements being added to the queue will happen asynchronously from a background
gRPC thread. Rather than immediately returning if the queue is empty allow
waiting up to 10 microseconds (possibly not optimal duration, but testing shows
good results -- before ~51% of cpu time is spent in `StreamingRead.read`, after
~13% of cpu time is spent in `StreamingRead.read` for roughly the same wall time
1.59% before, 1.52% after. This also has the added benefit of reduced perceived
latency for an application.

##### profiled workload results
Download 128MiB object from 0-EOF 1000 times, while async profiler is profiling
`event=cpu`. Using `StorageDataClient.fastOpenReadSession` to begin the read
while creating the session.

All values below are latency in milliseconds

|        |   p50 |   p90 |   p95 |
|--------|------:|------:|------:|
| before | ~ 266 | ~ 408 | ~ 468 |
| after  | ~ 253 | ~ 384 | ~ 431 |

* Remove no longer necessary Buffers.totalRemaining call
BenWhitehead requested a review from a team October 2, 2025 23:40
product-auto-label Bot added size: m Pull request size is medium. api: storage Issues related to the googleapis/java-storage API. labels Oct 2, 2025
bajajneha27 previously approved these changes Oct 3, 2025
BenWhitehead merged commit 678fecc into main Oct 6, 2025
25 checks passed
BenWhitehead deleted the fix/brs/less-cpu branch October 6, 2025 17:41
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

api: storage Issues related to the googleapis/java-storage API. size: m Pull request size is medium.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants


Back | FazBrowse Home | New Git URL