Repository navigation
Conversation
Ravel reads cold statements as ranged GETs. On a single drive RustFS serves each ranged GET by reading the whole 1 MiB erasure block around it, about 1.5 MB of disk per 10 KB range measured on c6a.4xlarge, so the cold figures measured the store's read amplification more than the database. s3s-fs serves a range with one file read. Both are single-node S3 servers over the machine's disk; the entry stays a local-disk entry with nothing required from the operator. ./install downloads the s3s-fs binary for the host architecture from a release on the NOFireAI/s3s fork (s3s-fs-0.17.0-ravel.1: the v0.17.0 release plus listing ETags, s3s-project/s3s#1013, which Ravel's store qualification requires, and keys read from the environment, s3s-project/s3s#1014, so no key sits in a process argument list) and verifies it against that release's SHA256SUMS before moving it into place, the way Ravel's own binaries are installed. When the release is unreachable it builds the same pinned commit with cargo install --locked, so what runs is fixed by content either way; the commit installed is recorded beside the binary. RustFS is gone from the entry: nothing downloads it. rustfs-start becomes store-start, the store directory is store/ and the generated keys are STORE_ACCESS_KEY and STORE_SECRET_KEY. The README gains a section on the store that states the swap and the measured reason for it.
One run of the entry as it stands (s3s-fs from the fork release, verified against its SHA256SUMS; the published v0.26.0 binaries verified against the release's SHA256SUMS) on a fresh c6a.4xlarge with this repository's Ubuntu 24.04 image, through the entry's own benchmark.sh. Cold sum 172.8 s against 365.7 s for the same binaries on RustFS (results/20261025); hot 57.0 s, QPS 0.733, error ratio 0.041, 43 of 43 answered, answers equal to the RustFS run's. The RustFS results stay under their own date.
Install the v0.27.0 release by default, and replace the c6a.4xlarge results file with a run of the entry as it stands on that release (s3s-fs from the fork release, the published v0.27.0 binaries verified against the release's SHA256SUMS): cold sum 163.1 s, hot 51.6 s, concurrent QPS 0.792, error ratio 0.054, 43 of 43 answered. On v0.26.0 the same entry measured 172.8 s cold and 57.0 s hot. The README's resolved-defaults sentence and the cold-sum history carry the v0.27.0 figures.
Add a MemTotal tier at 30 GB to ./load: target 3,700,000,000, one row group per object (--group-target-blocks 512), a 60 s age trigger, pipeline depth 56 and a 14,000,000,000-byte load budget. On c6a.4xlarge with v0.27.0 that writes 223 objects of about 46 MB instead of 422 of about 24 MB, and each column of an object is one contiguous range. Machines below 30 GB keep the existing geometry. RAVEL_GROUP_TARGET_BLOCKS overrides the group setting; an empty value keeps the loader's default. Signed-off-by: Panagiotis Moustafellos <pmoust@nofire.ai>
Replace results/20261026/c6a.4xlarge.json with a run of the entry with the 30 GB tier, on the published v0.27.0 binaries and s3s-fs from the fork release: 222 objects, cold sum 117.7 s, hot 51.5 s, concurrent QPS 0.810, error ratio 0.051, load 875 s, 43 of 43 answered. The same release with the previous geometry measured 163.1 s cold and 51.6 s hot. The README's cold-sum sentence carries both figures. Signed-off-by: Panagiotis Moustafellos <pmoust@nofire.ai>
pmoust
requested a deployment
to
benchmark-approval
October 26, 2026 14:29 — with 
GitHub Actions
Waiting
GitHub Actions
Waiting
Contributor
This was referenced Oct 26, 2026
Contributor
Author
|
Folded into #2804, which now carries this change together with the rest of the entry update in one PR. |
This branch is waiting to be deployed
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.
Depends on #2804. The first three commits are #2804's; this PR adds the last two, and I will rebase it once #2804 merges.
What changes.
./loadgets a memory tier at 30 GB and up. There it writes larger objects with one row group each:--target-bytes 3700000000and--group-target-blocks 512, a 60 s age trigger (--max-flush-delay), pipeline depth 56 and a 14,000,000,000-byte load budget. On c6a.4xlarge that gives 222 objects of about 46 MB instead of about 420 of 24 MB, and each column of an object is one contiguous range instead of one per row group. Machines below 30 GB keep the current geometry unchanged../start,queries.sqlandtemplate.jsonare unchanged, the server gets no performance flags, and the result stays"tuned": "no": like the existing tiers, this is the loader's object sizing chosen from the machine's memory, not a per-query setting.Measurement. Both columns are the entry run through its own
benchmark.shon a fresh c6a.4xlarge with this repository's Ubuntu 24.04 image, on the published Ravel v0.27.0 binaries and s3s-fs from the same fork release as #2804.The load takes about 90 s longer. Answers are equal on 41 of the 43 statements. The other two return different rows in every run, including two runs of the same geometry: q18 has
LIMITwithoutORDER BY, and q25 orders byEventTimebut returns onlySearchPhrase, so rows that tie on the timestamp at the limit can swap. Both vary between the three tries of a single run as well, on v0.25.1 and v0.26.0 as much as on v0.27.0.The tier applies to every machine whose
MemTotalis 30,000,000 kB or more. It was measured only on c6a.4xlarge; the other sizes are left to the usual re-run of the matrix.results/20261026/c6a.4xlarge.jsonis replaced with this run.