mirror of
https://github.com/block/buzz.git
synced 2026-11-09 02:41:57 +00:00
32997e2e1b
## Summary
A cold client in 280 channels can issue 280 separate membership reads,
each checking out a database connection. Cache the user's complete
active-membership set per community so those channel checks share one
read.
Keep the existing membership rules and 10-second freshness bound,
measured from connection checkout. Moka now accounts for snapshot size
with a 64 MiB weighted budget per relay. Each snapshot holds at most
16,384 UUIDs. The database pool controls query concurrency; there is no
separate 16-load limiter. Channel discovery keeps its separate filtering
rules. No schema change or migration.
### Request flow
1. Look up the community/user entry in Moka. A fresh complete snapshot
answers channel checks by binary search.
2. A fresh `PointChecks` marker sends each check to the database; it
stores no permission decision.
3. On a miss, create a lightweight, weighted loading entry. Requests for
that user share its lock.
4. Recheck after acquiring the lock. If waiting for that user’s lock
times out, use a point check.
5. Fetch at most 16,385 membership IDs. Above 16,384, retain a
`PointChecks` marker instead of a partial list.
6. Otherwise, sort the complete list into a compact immutable UUID
array.
7. Replace the loading entry through Moka. Its weigher now includes the
completed payload plus estimated bookkeeping.
8. Let Moka manage admission, eviction, and 10-second expiry. Membership
changes remove the relevant user or community entries.
Publication and invalidation share a short synchronous lock. A loader
publishes only while its original loading lock still identifies the
current entry. An old load can finish its original request, but cannot
repopulate an invalidated entry. Database failures propagate;
cancellation releases the user lock. Both database-query futures
allocate only when used, which keeps nested handler futures small. Cache
hits allocate neither query.
The budget covers estimated retained cache weight. Moka enforces it on a
best-effort basis; query buffers and snapshots held by active requests
can add memory. This is not a strict process-memory ceiling. Empty
entries and fallback markers have nonzero weight. There is no separate
memory-reservation or eviction implementation.
### Operational notes
- A newly granted membership can be absent from another relay's cached
snapshot until the Redis invalidation arrives, or until the 10-second
freshness bound expires if it is lost. Cached write checks can briefly
deny access; explicit channel subscriptions already confirm missing
membership against the database.
- `buzz_membership_cache_hits_total` counts channel checks served from a
fresh snapshot. `buzz_membership_cache_misses_total` counts bounded
full-set load attempts. Timeouts now use point checks, recorded by
`buzz_membership_cache_fallbacks_total{reason="wait_timeout"}`. The
other fallback reason is `oversize`; the `load_limit` path has been
removed. Before/after hit ratios are not directly comparable.
- Keep `channel_id` in membership invalidation messages for
compatibility with older relay instances during rolling deployments,
even though the new local cache invalidates by user.
### Related issue
Follow-up to #9012.
### Testing
**Current head: `a79a40cc5a6e4c7c611ed1b6bcbdd8b8c0490ef2`, including
main `f82944e3180e28502f5ea599ac9973aa6398ddb3`.** Commit `393b32583`
fixes the large-membership test fixture by refreshing planner statistics
after bulk seeding. Before that fix, the boundary test failed locally
and was the sole PostgreSQL test failure in GitHub CI (1,409/1,410
passed); the repaired test passes in 3.54 seconds including setup and
all checks. An isolated copy of the production schema/query at 16,384
memberships selected a quadratic join without statistics and a hash join
after `ANALYZE`; the latter executed in 10.86 ms. The cap and freshness
rules are unchanged.
At this exact head, the full regular buzz-db/buzz-relay suite passed
1,963/1,963 and the full PostgreSQL suite passed 1,310/1,310. This
includes both previously failing Git-auth cases and the repaired
membership boundary test (2.302 seconds including setup and checks).
Rebuilt signed live checks also passed. Full local `just ci` passed
(exit 0). GitHub CI is green: 79 successful checks and 31 skipped, with
none pending or failed at verification. The [verified matched A/B at
this
head](https://github.com/block/buzz/pull/9060#issuecomment-6673813172)
against main `f82944e31` is complete: four 6,600-client arms in both
orders show 90.98–91.24% fewer membership-cache queries and 73.76–74.23%
fewer authorization checkouts. Auth error rates improved in both orders;
auth p99 and overall operation errors were mixed. Average relay RSS
increased 1.6–4.3%, with flat to slightly lower sampled peaks;
PostgreSQL average PSS decreased 1.7–5.2%, with mixed peaks. The
16,384-row production query executed in 24.953 ms after fixture ANALYZE.
Signed pool-4 and 4,097/16,384/16,385-membership probes passed. See the
report for raw counts, memory, provenance and limitations. The
[completed A/B at the earlier `6f0358875`
head](https://github.com/block/buzz/pull/9060#issuecomment-6672419096)
is reported separately; it does not establish current-head performance.
Users above 16,384 memberships still use uncached authoritative point
checks. The higher cap reduces how many users hit that fallback; it does
not eliminate the cost. Each maximum-size list contains 256 KiB of UUIDs
plus overhead within the unchanged 64 MiB estimated cache budget.
Temporary allocations and retained readers can add memory outside that
budget.
Agent-run signed WebSocket test at
`a79a40cc5a6e4c7c611ed1b6bcbdd8b8c0490ef2`, using the rebuilt relay and
an isolated database: non-members cannot post; grants allow both private
channels; removal blocks writes and delivery from A while B continues;
re-add and resubscription restore A. Delivery checks completed in 1.776
s after removal and 0.466 s after re-add. A user grown above 5,000
memberships used snapshots with no oversize fallback. After growing
beyond 16,384, authoritative point checks still enforced removal and
re-add; four oversize fallbacks were recorded. The relay stopped and all
three test ports closed. Binary SHA-256:
`5b69a5aed07e9beef6bd6d2c5661c07fbdf1901dedb1729d27ab5e86a6b8d6a3`.
Build this head with `cargo build -p buzz-relay --bin buzz-relay` and
start an isolated local relay as described in
[TESTING.md](6f03588757/TESTING.md).
Reproduce with two accounts and two private channels: check denial
before membership, grant both, remove one, then re-add. Subscribe to
both channels during the test. At the current head, verify a user with
5,000 memberships still uses snapshots, then give the second account
more than 16,384 memberships and repeat the permission checks through
the fallback path. This was agent verification; human confirmation is
still pending.
#### Historical load test, before the memory-bound refactor
These measurements apply to `519509451`, before weighted eviction, the
per-user cap, and bounded loads. The refactored version was subsequently
measured at `6f0358875`; see the linked report above. The current-head
comparison is complete and reported separately
[above](https://github.com/block/buzz/pull/9060#issuecomment-6673813172).
Compared base `f9ef721e688847ed0c1512081160b6e42cdf92fd` with head
`519509451c10d94074f597124d19f2254f0b96d1` on a dedicated Linux
workstation. Ran base → fix, then fix → base. Each arm used 6,600
clients, 100 connects/second, six generator shards, and a 300-second
hold. Both versions used pool size 50, the same notices index, CPU
allocation, restored fixture, and load generator
(`4813b8cd15411355f05599e263ab15dd04e7afcc`). All four arms and 24 shard
reports completed; recorded binary hashes, fixture manifests, index DDL,
and shard configurations were verified.
| Metric | First pair: base | First pair: fix | Reverse pair: base |
Reverse pair: fix |
|---|---:|---:|---:|---:|
| Per-channel membership query calls | 1,319,382 | 7,205 | 1,367,525 |
7,465 |
| All membership-related query calls | 1,419,429 | 216,639 | 1,457,453 |
220,253 |
| Membership query execution time | 19.55 s | 10.55 s | 18.89 s | 10.74
s |
| Authorization pool checkouts | 1,667,944 | 457,649 | 1,690,624 |
453,910 |
| Average relay CPU, cores | 3.43 | 2.32 | 2.29 | 2.00 |
| Server authentication timeouts | 5,613 | 3,832 | 3,152 | 3,120 |
| Client authentication p99, highest shard | 8.378 s | 7.010 s | 6.349 s
| 6.606 s |
The cache reduced per-channel membership reads by 99.45%, all
membership-related calls by 84.7–84.9%, and authorization checkouts by
72.6–73.2%. Relay CPU was 12.7–32.4% lower. These runs support an
efficiency improvement, but do not establish a repeatable
authentication-latency or timeout improvement.
The pool still saturated. Mean authorization checkout wait increased
from 176.6 to 486.2 ms in the first pair and 118.6 to 442.6 ms in
reverse order. Removing cheap checkouts changes that average's
denominator; it does not isolate latency changes for equivalent
requests. Both versions retained client errors. Memory usage did not
consistently improve.
Each arm restored the fixture and started with a cold relay cache, but
Linux page cache was not dropped. The first baseline arm performed
materially worse than later arms. Operation counts differed with
reconnects and failures. Reported p99 is the maximum shard p99, not a
merged percentile. No perf profile was collected.
Reproduction with the reviewed harness (build exact commits above as
`base` and `fix`; optional delayed profiler disabled and complete
query/metric collection enabled):
```bash
RUN=pr9060_ab EXTRA_ENVS="BUZZ_DB_POOL_SIZE=50" \
ARMS="current:scen=bbcold.toml:rate=100:relay=base:sql=nidx.sql current:scen=bbcold.toml:rate=100:relay=fix:sql=nidx.sql" \
bash ~/lt-src/bb.sh
RUN=pr9060_ba EXTRA_ENVS="BUZZ_DB_POOL_SIZE=50" \
ARMS="current:scen=bbcold.toml:rate=100:relay=fix:sql=nidx.sql current:scen=bbcold.toml:rate=100:relay=base:sql=nidx.sql" \
bash ~/lt-src/bb.sh
```
Generated with Codex
---------
Signed-off-by: Ravneet Arora <rarora@squareup.com>
Co-authored-by: maincourse <37ce551b493d4a998caf030929c47bce0b6a0e43f1178b3a63c4151d7c16b76e@buzz.block.builderlab.xyz>
102 lines
3.5 KiB
Rust
102 lines
3.5 KiB
Rust
#![deny(unsafe_code)]
|
|
#![warn(missing_docs)]
|
|
//! NIP-01 WebSocket relay for Buzz private team communication.
|
|
|
|
/// Stdout access log: reads, auth attempts, and connection lifecycle.
|
|
pub(crate) mod access;
|
|
mod admission;
|
|
mod build_info;
|
|
mod community_active;
|
|
mod host_cache;
|
|
mod rejection;
|
|
|
|
/// Shared NIP-FI assertion evaluation, denial rendering, and key pairing.
|
|
pub(crate) mod nip_fi_core;
|
|
/// NIP-FI session admission gate — per-connection effect-permit and quiescence barrier.
|
|
pub(crate) mod nip_fi_gate;
|
|
pub(crate) mod nip_fi_session;
|
|
pub(crate) mod nip_fi_shadow;
|
|
pub(crate) mod nip_fi_shadow_session;
|
|
/// NIP-FI test hooks — production barriers for deterministic B1/B2 witnesses.
|
|
#[cfg(test)]
|
|
pub(crate) mod nip_fi_test_hooks;
|
|
/// NIP-FI assertion validation at WebSocket upgrade.
|
|
pub(crate) mod nip_fi_upgrade;
|
|
|
|
/// REST API route handlers.
|
|
pub mod api;
|
|
/// WebSocket audio relay for huddle voice channels.
|
|
pub mod audio;
|
|
/// Relay configuration from environment variables.
|
|
pub mod config;
|
|
/// Runtime conformance harness — abstract trace emission at the
|
|
/// ingest/read accept-reject boundary, replayed against
|
|
/// `docs/spec/MultiTenantRelay.tla` by the independent `buzz-conformance`
|
|
/// checker.
|
|
pub mod conformance;
|
|
/// WebSocket connection lifecycle and state.
|
|
pub mod connection;
|
|
/// Relay error types.
|
|
pub mod error;
|
|
/// WebSocket message handlers for NIP-01 client commands.
|
|
pub mod handlers;
|
|
/// Stateless HMAC-signed relay invite tokens (mint/verify).
|
|
pub mod invite_token;
|
|
/// Fixed-schema evidence for the relay's earliest startup steps.
|
|
pub mod lifecycle;
|
|
mod membership_cache;
|
|
/// Inter-relay mesh startup wiring (`BUZZ_MESH` seam).
|
|
pub mod mesh_boot;
|
|
/// Prometheus metrics: recorder, upkeep, HTTP middleware.
|
|
pub mod metrics;
|
|
/// NIP-11 relay information document.
|
|
pub mod nip11;
|
|
mod nip98;
|
|
/// NIP-FI relay configuration: mode, issuer registry, JWKS warm/refresh.
|
|
pub mod nip_fi_config;
|
|
/// NIP-FI HTTP ingress enforcement: assertion extraction, verification,
|
|
/// key-pairing check, and deny-map gate for every protected HTTP surface.
|
|
pub(crate) mod nip_fi_http;
|
|
pub(crate) mod nip_fi_policy;
|
|
pub mod nip_fi_resolver;
|
|
/// Deployment-global operator-listener mention delivery worker.
|
|
pub mod operator_listener;
|
|
/// NIP-01 client/relay message parsing.
|
|
pub mod protocol;
|
|
/// Durable NIP-PL matcher and delivery worker.
|
|
pub mod push_runtime;
|
|
/// Readiness-probe telemetry and the per-pod dependency sampler behind `/_status`.
|
|
pub mod readiness;
|
|
/// Axum router construction.
|
|
pub mod router;
|
|
/// Per-key gates that let concurrent cache misses share one database read.
|
|
mod shared_reads;
|
|
/// Timing for startup work between metrics bind and serving.
|
|
pub mod startup_steps;
|
|
/// Shared application state.
|
|
pub mod state;
|
|
pub mod storage_sweep;
|
|
/// Push each new per-community storage snapshot to an operator endpoint.
|
|
pub mod storage_usage_delivery;
|
|
/// Subscription registry with (channel, kind) fan-out index.
|
|
pub mod subscription;
|
|
/// OpenTelemetry tracing initialisation (tracer provider + OTLP exporter).
|
|
pub mod telemetry;
|
|
/// Row-zero host binding: resolve the request community from the connection host.
|
|
pub mod tenant;
|
|
#[cfg(test)]
|
|
mod test_support;
|
|
/// Relay-side tunnel session directory and routing.
|
|
pub mod tunnel;
|
|
/// Webhook secret generation and constant-time comparison.
|
|
pub mod webhook_secret;
|
|
/// Workflow action sink — relay-side implementation of [`buzz_workflow::ActionSink`].
|
|
pub mod workflow_sink;
|
|
|
|
pub use config::Config;
|
|
pub use error::{RelayError, Result};
|
|
pub use state::AppState;
|
|
|
|
/// Optional relay-signed verified profiles.
|
|
pub mod verified_profiles;
|