Add solbench methods: per-method read-latency matrix (roadmap 6) - #1
Open
jenish-25 wants to merge 4 commits into
Open
Add solbench methods: per-method read-latency matrix (roadmap 6)#1jenish-25 wants to merge 4 commits into
jenish-25 wants to merge 4 commits into
Conversation
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
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.
Summary
Ships the first piece of roadmap item 6: a per-method read-latency matrix via a new
solbench methodssubcommand. Todayprobemeasures one hardcoded method (getSlot); thismeasures a set of read methods across every endpoint and reports a latency distribution per
(method × endpoint).
Motivation: different RPC methods carry different server-side cost, so a matrix lets you compare
endpoints within a method and see relative method cost — an honestly-labeled distribution
metric, which
CONTRIBUTING.mdcalls out as especially welcome.What's included
solbench methods --samples N --interval-ms M [--account <pubkey>] [--json]— measuresgetSlot,getVersion,getLatestBlockhash,getAccountInfo,getMultipleAccounts.extracted from
probe.rs::run_endpointinto a sharedsample_endpoint(...), soprobeandmethodsmeasure identically.getSlot/slot-lag behavior is preserved exactly (a thinextractclosure), andprobe_all/ProbeResultare unchanged.sysvars (Clock / Rent / RecentBlockhashes), which exist on any cluster;
--accountoverrides thegetAccountInfotarget.host, to compare endpoints within a method (not across), that methods run in sequence, and
which fixed accounts are used.
solbench-coreis untouched — no new math there, so the "keep core network-free" rule holds.Example
--jsonemits[{ "method", "results": [{ "label", "host", "ok", "errors", "latency" }] }].Testing
cargo fmt --all --check,cargo clippy --all-targets --all-features -- -D warnings, andcargo test --allall pass locally. New tests use a hermetictiny_httpserver (no live network):sample_endpointrecords latency + extracts values, and counts malformed responses as errors;probe_methodsproduces a per-method report with latency;method_specsare well-formed JSON with the right method/params;methods_extractdistinguishesresultvserror.Notes
--samplesacross five methods; defaults are modest.separate change. Happy to adjust the method set, output columns, or naming to your preferences.