Skip to content

test: add benchmark test suite for blobstore async client#398

Open
roseyang62 wants to merge 4 commits intosalesforce:mainfrom
roseyang62:benchmark/directory-upload-download
Open

test: add benchmark test suite for blobstore async client#398
roseyang62 wants to merge 4 commits intosalesforce:mainfrom
roseyang62:benchmark/directory-upload-download

Conversation

@roseyang62
Copy link
Copy Markdown
Contributor

Summary

< Provide a brief description of the changes in this PR >

Some conventions to follow

  1. add the module name as a prefix
    • for example: add a prefix: docstore: for document store module, blobstore for Blob Store module
  2. for a test only PR, add test:
  3. for a perf improvement only PR, add perf:
  4. for a refactoring only PR, add "refactor:"

@roseyang62 roseyang62 changed the title blob: add benchmark test suite for async client test: add benchmark test suite for blobstore async client Apr 24, 2026
@codecov-commenter
Copy link
Copy Markdown

codecov-commenter commented Apr 24, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.07%. Comparing base (5ae51cc) to head (7263d7f).

Additional details and impacted files
@@            Coverage Diff            @@
##               main     #398   +/-   ##
=========================================
  Coverage     82.07%   82.07%           
  Complexity      641      641           
=========================================
  Files           194      194           
  Lines         11848    11848           
  Branches       1578     1578           
=========================================
  Hits           9724     9724           
  Misses         1447     1447           
  Partials        677      677           
Flag Coverage Δ
unittests 82.07% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@roseyang62 roseyang62 marked this pull request as ready for review April 27, 2026 16:48
*
* <p>Runs in {@link Mode#SampleTime}, {@link Mode#SingleShotTime} and {@link Mode#Throughput}.
*
* <p>Corpus: 100 x 1KB, 50 x 1MB, 10 x 10MB — kept under AWS/GCS rate limits.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do 100 × 1 KB, 50 × 1 MB, and 10 × 10 MB represent?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I got it. It's the Corpus size.

@Warmup(iterations = 1, time = 60, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 60, timeUnit = TimeUnit.SECONDS)
@Fork(1)
@Threads(1)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just single thread?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Single threaded test measures the SDK‘s internal async concurrency - how fast it can upload N files in parallel within a single operation.
Should we test with multiple threads?

Copy link
Copy Markdown
Contributor Author

@roseyang62 roseyang62 Apr 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also one quick question on intent. what's the main thing we want this benchmark to answer?

  • Single-op latency: how long does one uploadDirectory / downloadDirectory call take? (what @threads(1) gives us today)
  • Caller-side concurrency: how does multicloudj hold up when N directory ops run in parallel? (would need @threads(N))
  • Or both

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, ideally we need the tests with real world scenarios, less likely there will be a client using parallel operations with single thread, it doesn't make much sense. We should test the parallel operations with multiple threads maybe like 4?

We can definitely the single thread as well just I believe multi-thread is the more realistic.

uploadPrefix = null;
}
if (downloadDest != null) {
deleteLocalRecursive(downloadDest);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think should cleanup before executing as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants