[indexer] Standalone synthetic ingestion #20270
Merged
Conversation
This file contains 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
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
3 Skipped Deployments
|
lxfind
temporarily deployed
to
sui-typescript-aws-kms-test-env
GitHub Actions
Inactive
lxfind
force-pushed
the
standalone-synthetic-ingestion
branch
from
9be316b to
895565e
Compare
lxfind
temporarily deployed
to
sui-typescript-aws-kms-test-env
GitHub Actions
Inactive
lxfind
force-pushed
the
standalone-synthetic-ingestion
branch
from
895565e to
a93b934
Compare
lxfind
temporarily deployed
to
sui-typescript-aws-kms-test-env
GitHub Actions
Inactive
wlmyng
approved these changes
Nov 20, 2024
| fs::remove_file(ingestion_dir.join("1.chk")).await.unwrap(); | ||
| effects.created()[0].0 | ||
| }; | ||
| sim.override_next_checkpoint_number(starting_checkpoint); |
There was a problem hiding this comment.
ah so this is what will set the next checkpoint file to starting_checkpoint.chk
Comment on lines
124
to
127
| println!( | ||
| "About to build checkpoint, size: {}", | ||
| self.transactions.len() | ||
| ); |
There was a problem hiding this comment.
do we want this println still?
gegaowp
approved these changes
Nov 20, 2024
| let bytes = tokio::fs::read(&path).await.unwrap(); | ||
| let checkpoint_data: CheckpointData = Blob::from_bytes(&bytes).unwrap(); | ||
| if checkpoint_data.transactions.len() != checkpoint_size as usize { | ||
| for tx in &checkpoint_data.transactions { |
There was a problem hiding this comment.
why do we want to print here, as there is another assert below?
assert_eq!(checkpoint_data.transactions.len(), checkpoint_size as usize);
| // `request_gas` will create a transaction, which we don't want to include in the benchmark. | ||
| // Put it in a checkpoint and then remove the checkpoint file. | ||
| sim.create_checkpoint(); | ||
| fs::remove_file(ingestion_dir.join("1.chk")).await.unwrap(); |
There was a problem hiding this comment.
is remove_file necessary? as std::fs::write(path.join(file_name), blob.to_bytes())?; will overwrite 0.chk and 1.chk after override_next_checkpoint_number
- if the test range covers cp 0 and cp 1, it will overwrite
- otherwise these 2 files are not used?
There was a problem hiding this comment.
I was hoping to have a mode where when you run benchmark from an ingestion dir, it automatically scan through all files in it
lxfind
temporarily deployed
to
sui-typescript-aws-kms-test-env
GitHub Actions
Inactive
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Decouples ingestion and benchmarking, remove the benchmark related code from sui-indexer crate.
After this change, we will always first run synthetic ingestion to generate a workload, and then separately, run indexer to benchmark it.
This has a few benefits:
Also cleaned up the ingestion generation code by allowing generation from checkpoint 0, and made sure that every checkpoint has the same number of transactions.
Test plan
Updated tests.
Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.