Files
amethyst/relayBench/README.md
T
Claude 58c580cd34 feat(geode): --no-search / [options].full_text_search — run without NIP-50
strfry implements no NIP-50 at all, so geode's default setup pays FTS
tokenization on every searchable event for a feature the other side of a
benchmark isn't providing. The new switch removes it cleanly:

- geode: --no-search CLI flag and [options].full_text_search TOML key
  (default true). When off, the store skips the FTS index entirely,
  NIP-11 stops advertising 50 (an explicit [info] nips list stays
  operator-authoritative), and search filters match nothing via the
  existing QueryBuilder guard. RelayIndexingStrategy becomes
  relayIndexingStrategy(fullTextSearch) with the stock val kept.

- relayBench: --geode-no-search runs the geode entry with the flag (relay
  named geode-nosearch in reports); README documents the apples-to-apples
  rationale and a recipe for benchmarking both geode flavors side by side.

Alternating A/B on the 10k corpus: 4,767/4,792 ev/s without search vs
4,111/3,977 with — NIP-50 costs ~18% of ingest throughput at current
write-path speed.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NeoCvXnTxsKzqurkmjdC46
2026-07-03 18:37:39 +00:00

133 lines
6.9 KiB
Markdown

# relayBench
Head-to-head benchmark for Nostr relay implementations. Boots each relay as a
real external process on loopback under an equivalent setup — persistent
storage, signature verification on, no auth, stock limits — replays the same
event corpus into each, and renders a side-by-side report.
```bash
./relayBench/run.sh # geode vs strfry, 10k-event synthetic corpus
./relayBench/run.sh --quick # 2k-event smoke run
./relayBench/run.sh --real # replay the checked-in real-event dump (2024, ~30k events)
```
`run.sh` builds `:geode:installDist` and the harness, and resolves strfry from
`$STRFRY_BIN`, the `PATH`, or by building it from source into
`relayBench/.cache/` (first run only). `SKIP_STRFRY=1` / `SKIP_GEODE=1` skip a
side.
## What is measured
**Ingest — receipt ➜ queryable.** One connection publishes an event; from the
same instant a second connection hammer-polls `REQ {"ids":[id]}` until the
event comes back. This measures exactly "how long after the relay receives an
event can a REQ return it", which is not the same thing as the OK ack — the
report also shows OK latency and what fraction of events were already
queryable when their OK arrived.
**Ingest — throughput.** The corpus is replayed over N connections (default 4)
with a bounded number of unacked EVENTs in flight, wall-clocked from first
send to last OK. Accepted/rejected counts come from the OKs.
**Queries.** Filters modeled on what real clients send, derived from the
corpus itself so they hit meaningful data: global feed, profile hydration,
home feed (150 follows), hottest thread, notifications for the most-mentioned
pubkey, hashtag feed, 100-id batch fetch, recent time window. Each runs
warmup + measured rounds on one connection (time-to-first-event / time-to-EOSE
percentiles) and then from 8 connections at once (aggregate events/second).
All filters stay inside strfry's default limits, and the number of events each
relay returns is cross-checked — a ⚠ in the report means the relays disagree
about the result set, which invalidates the speed comparison for that row.
**NIP-77 negentropy sync — every pair of relays.** Both sides get an 80% slice
of the corpus (60% overlap); the harness plays the `strfry sync` role with one
side's dataset as its local set and measures: initial reconciliation against
each relay as server (time, NEG-MSG rounds, wire bytes), the delta transfer to
convergence, and the steady-state reconcile of identical sets. Convergence is
verified, so this doubles as an interop test.
**Storage.** On-disk footprint after full ingest (LMDB vs SQLite vs whatever).
## Corpora
The corpus is the controlled variable: every relay sees the same events in
the same order, and reports carry a `fingerprint` (sha256 over event ids) so
two runs are comparable only when fingerprints match.
| source | flag | notes |
|---|---|---|
| **synthetic** (default) | `--events N --seed S` | Deterministic to the byte: seeded keys, fixed timestamps, seed-derived BIP-340 nonces. Same spec ⇒ identical NDJSON on any machine. Zipf-popularity authors, threads, reactions, reposts, zap pairs, hashtags. |
| **real dump** | `--real` | The `quartz` test fixture `nostr_vitor_startup_data.json.gz` — ~31k unique real events from 2024 with a rich kind mix (notes, chats, DMs, zaps, reports, communities). |
| **contact lists** | `--corpus contact-lists.gz --limit 100000 --max-event-bytes 1048576 --max-tags 20000` | 2.1M real kind-3 contact lists (heavy events, ~1.3 kB avg, up to 100+ kB). Grab it with `pip install gdown && gdown 1yyC93xY9sDsEsa351ZAMhtAXwBUh3LYT`. Raising the size/tag caps reconfigures strfry to match, so both relays still accept the full stream. |
| **any dump** | `--corpus FILE` | NDJSON or a single JSON array, gzipped or plain (sniffed by magic bytes). |
| **fresh download** | `--download [urls]` | Pages recent events out of public relays (damus/nos.lol/primal by default). |
Every source goes through the same preparation: dedup by id, drop unsigned
events (NIP-17 rumors), kind-5 deletions and ephemerals (order-dependent or
unqueryable — they would make relays disagree for reasons unrelated to
performance), drop events over the size/tag caps, verify every Schnorr
signature in parallel, sort chronologically. The prepared corpus is cached in
`relayBench/.corpus-cache/` as NDJSON next to a `manifest.json` with the
fingerprint and kind histogram — that file pair is a shareable, citable
benchmark artifact.
> **Why this corpus matters:** there is no de-facto community benchmark corpus
> today. Existing relay benchmarks (rnostr's and privkeyio's nostr-bench,
> mattn's scripts) each synthesize their own events with unspecified
> distributions, so published numbers aren't reproducible corpus-controlled;
> the only shared dataset (Wellorder's early-1m) is frozen in January 2023.
> relayBench's synthetic spec ("seed 1, n=10000, v1" ⇒ byte-identical corpus)
> and manifest/fingerprint convention are designed so other relay authors can
> run the exact same workload and publish comparable numbers.
## Feature parity: NIP-50 search
geode maintains a NIP-50 full-text index by default; strfry has no search
at all. That skews the *ingest* comparison — geode tokenizes every
searchable event into the FTS index (~a quarter of its write cost) for a
feature strfry isn't providing. `--geode-no-search` runs geode with
`--no-search` (no FTS index, NIP-11 stops advertising 50) for the
apples-to-apples write path:
```bash
./relayBench/run.sh --geode-no-search # geode(no NIP-50) vs strfry
```
To see the price of search inline, run both geode flavors side by side:
```bash
GEODE=geode/build/install/geode/bin/geode
./relayBench/run.sh --geode-no-search \
--relay "geode-fts=$GEODE --host 127.0.0.1 --port {port} --db {dir}/geode.sqlite"
```
## Adding another relay
No code needed if the relay can be launched from a command line:
```bash
./relayBench/run.sh --relay 'nostr-rs-relay=/usr/bin/nostr-rs-relay --db {dir} --port {port}'
```
`{port}` and `{dir}` are substituted at launch; the process must listen on
`127.0.0.1:{port}` with persistent storage under `{dir}`, verification on and
no auth. If the relay needs a config file, point the template at a small
wrapper script that writes one (see `StrfryRelay` in
`relays/RelayUnderTest.kt` for the pattern — adding a first-class subclass is
~20 lines).
## Output
The terminal report shows each metric as name / bar / value rows with the
winner starred, followed by a head-to-head summary. Every run also writes:
- `relayBench/results/<timestamp>/report.md` — shareable Markdown
- `relayBench/results/<timestamp>/results.json` — raw numbers for tooling
## Direct harness invocation
`run.sh` is a thin wrapper; the harness itself is
`relayBench/build/install/relaybench/bin/relaybench` — see `--help` for all
options (`--samples`, `--publishers`, `--window`, `--query-rounds`,
`--query-conns`, `--no-sync`, `--out`, `--keep-data`, …).