[indexer-alt] Add benchmark command #20352
Conversation
|
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
crates/sui-indexer-alt/src/args.rs
Outdated
| #[clap(long)] | ||
| consistent_range: Option<u64>, | ||
| #[command(flatten)] | ||
| sequential_pipeline_config: SequentialPipelineConfig, |
There was a problem hiding this comment.
nit: this is even more specific than for sequential pipelines -- let's call it a ConsistencyConfig or something?
crates/sui-indexer-alt/src/lib.rs
Outdated
| // If true, the indexer will bootstrap from genesis. | ||
| // Otherwise it will skip the pipelines that rely on genesis data. | ||
| with_genesis: bool, |
There was a problem hiding this comment.
Is it worth doing this the other way? I.e. infer whether we need to bootstrap genesis based on whether the pipelines we're about to run need it or not? Seems like that would be less error-prone.
There was a problem hiding this comment.
Is there a better way to infer that other than hardcode the list of pipelines that need genesis somewhere?
There was a problem hiding this comment.
Hardcoding it is really the only way, but it's driven by the types, because the pipelines that need bootstrapping need a value that is only generated from the bootstrapping process to initialise themselves with.
lxfind
force-pushed
the
indexer-alt-benchmark
branch
from
b914ad1
to
97010a3
Compare
lxfind
temporarily deployed
to
sui-typescript-aws-kms-test-env
GitHub Actions
Inactive
There was a problem hiding this comment.
Looks good! Just some small nits.
There's also the small thread about bootstrapping genesis -- as I was thinking about it, that discussion dove-tails with a separate discussion in the standalone synthetic benchmark generation logic where you get rid of checkpoint 0 -- is it worth simplifying things by keeping both? I.e. simulacrum always generates the genesis checkpoint, and we always bootstrap the genesis table, even during benchmarks?
|
|
||
| [features] | ||
| default = [] | ||
| benchmark = ["sui-synthetic-ingestion"] # This will be used to enable benchmark mode |
There was a problem hiding this comment.
This is mostly for my own education -- in some places, I've seen this written like it is here, and in other cases the feature name is prefixed with a "dep:" when it enables the dependency.
Is there a difference between the two?
There was a problem hiding this comment.
Good question. I am now confused on the difference too.
| pipeline: Vec<String>, | ||
|
|
||
| #[command(flatten)] | ||
| sequential_pipeline_config: ConsistencyConfig, |
There was a problem hiding this comment.
nit: naming.
| sequential_pipeline_config: ConsistencyConfig, | |
| consistency_config: ConsistencyConfig, |
There was a problem hiding this comment.
nit: I don't think this belongs inside pipeline -- it's specific to our indexer, while pipeline is part of the indexer framework. Let's keep it at the top-level for now.
I was hoping to be able to also download some checkpoint data from mainnet, and use them to benchmark the indexer. The genesis checkpoint would not be there. |
lxfind
temporarily deployed
to
sui-typescript-aws-kms-test-env
GitHub Actions
Inactive
Description
This PR adds a benchmark command to indexer-alt.
It would start the indexer using the provided parameters, start and stop based on the local ingestion data.
It then measures the time and TPS.
A few structural changes to indexer-alt code:
Test plan
Run locally
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.