Skip to content

chore(storage): add storage benchmark tool for Gaxios refactor comparison#8341

Open
thiyaguk09 wants to merge 12 commits into
googleapis:storage-node-18from
thiyaguk09:chore/344856049-gaxios-benchmark
Open

chore(storage): add storage benchmark tool for Gaxios refactor comparison#8341
thiyaguk09 wants to merge 12 commits into
googleapis:storage-node-18from
thiyaguk09:chore/344856049-gaxios-benchmark

Conversation

@thiyaguk09
Copy link
Copy Markdown
Contributor

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

  • Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
  • Ensure the tests and linter pass
  • Code coverage does not decrease (if any source code was changed)
  • Appropriate docs were updated (if necessary)

Fixes #<issue_number_goes_here> 🦕

…sport (googleapis#8283)

- Remove Service.ts and common.ts files from handwritten/storage

- Migrate remaining functionality to StorageTransport

- chore(ci): upgrade conformance tests to Node 18
…sport (googleapis#8283)

- Remove Service.ts and common.ts files from handwritten/storage

- Migrate remaining functionality to StorageTransport

- chore(ci): upgrade conformance tests to Node 18
@product-auto-label product-auto-label Bot added the api: storage Issues related to the Cloud Storage API. label May 21, 2026
Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

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

Code Review

This pull request introduces a new benchmarking tool in handwritten/storage/internal-tooling/benchmark.ts along with updated documentation in the README. The tool enables comparative latency and memory benchmarking between the current codebase and a specified baseline NPM version of @google-cloud/storage. Feedback focuses on improving the robustness of dynamic imports for module compatibility, replacing hardcoded values with constants, enhancing type safety by avoiding any[], and refining the throughput calculation logic.

Comment thread handwritten/storage/internal-tooling/benchmark.ts Outdated
Comment thread handwritten/storage/internal-tooling/benchmark.ts Outdated
Comment thread handwritten/storage/internal-tooling/benchmark.ts Outdated
Comment thread handwritten/storage/internal-tooling/benchmark.ts Outdated
@thiyaguk09 thiyaguk09 marked this pull request as ready for review May 21, 2026 08:26
@thiyaguk09 thiyaguk09 requested a review from a team as a code owner May 21, 2026 08:26
Comment on lines +67 to +68
async function runBenchmark(StorageClass: typeof Storage, name: string, bucketName: string) {
// 2. Pass custom project ID to the storage client
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.

Nit: Is this comment required ? What do the numbers on the comment refer to ?

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.

Removed prefix numbers (e.g., // 1., // 2.) from all comments and simplified them to clean, standard developer comments.


| Parameter | Description | Requirement | Default |
| --------- | ----------- | :---: | :---: |
| `--project` | Google Cloud Project ID | **Required** | - |
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.

Nit: Can we use projectId as the flag name like the other files in this folder for standardization ?

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.

Changed the --project option in benchmark.ts to --projectid.


try {
// Scenario 1: Upload Small File
console.log('Starting Scenario 1: Upload (1KB)...');
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.

Consider dividing this into helper functions for each test scenario.

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.

Extracted individual scenario logic out of the main runBenchmark function into distinct, reusable async helper functions:

  • runUploadScenario(bucket, content, name, uploadedFiles)
  • runMetadataScenario(mainFile)
  • runDownloadScenario(mainFile)

logMemory('After Metadata');

// Scenario 3: Download Small File
console.log('Starting Scenario 3: Download (1KB)...');
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.

Is there a reason for only choosing only 1KB file size? Can we make this parameterized for other file sizes as well ?

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.

Are there other operations which are affected by the migration ?
Some possible examples: Large file transfers, Resumable uploads. If yes we should be benchmarking them as well to make sure we do not see any regression in them due to the migration

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.

Is there a reason for only choosing only 1KB file size? Can we make this parameterized for other file sizes as well ?

Introduced the --fileSize option (defaulting to 1024 bytes) in yargs. The file size buffer is now allocated dynamically (Buffer.alloc(argv.fileSize, 'a')), and throughput calculations adapt to the configured file size.

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.

Are there other operations which are affected by the migration ? Some possible examples: Large file transfers, Resumable uploads. If yes we should be benchmarking them as well to make sure we do not see any regression in them due to the migration

Agreed! Our resumable uploads currently only support/rely on Gaxios, so testing this path is crucial. To support better benchmarking here, I've added a --resumable boolean flag option. Under the hood, runUploadScenario passes this flag to the storage iterFile.save(content, { resumable: argv.resumable }) option, enabling targeted performance testing of resumable uploads.

@Dhriti07 Dhriti07 requested a review from kalragauri May 25, 2026 07:08
@thiyaguk09 thiyaguk09 requested a review from a team as a code owner May 25, 2026 08:43
@thiyaguk09 thiyaguk09 requested a review from Dhriti07 May 25, 2026 16:05
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 Cloud Storage API.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants