feat(relay): make Redis pool size configurable, default 16 - #2521
Merged
Conversation
deadpool-redis defaults its pool max to CPU_COUNT * 2, which on a 2-vCPU relay pod is only 4 connections shared by rate limiting, presence, pub/sub publishes, and cache invalidation. bb-public pods started showing pool waiters (buzz_redis_pool_waiting > 0, buzz_redis_pool_max = 4) at ~190 events/s. Raise the default to 16 and expose BUZZ_REDIS_POOL_SIZE for per-deploy tuning. Zero or unparsable values fall back to the default. Co-authored-by: Tyler Longwell <tlongwell@block.xyz> Signed-off-by: Tyler Longwell <tlongwell@block.xyz>
yoamomonstruos
added a commit
that referenced
this pull request
Jul 23, 2026
…arch * origin/main: Refine channel lifecycle settings (#2427) Fix avatar upload lifecycle edge cases (#2277) fix(observer): eager archive hydration on panel open + 200-frame pages (#2574) fix(cli): install rustls crypto provider to unbreak WSS publishes in release builds (#2590) feat(dev): add `just production` recipe targeting the production relay (#2572) chore: Omit the Model control when an optional-model harness has nothing to select (#2262) fix(ci): stop moving protected Sprig rolling tag (#2221) fix(media): sanitize animated image uploads (#2524) fix(desktop): populate team instructions when opening the edit team dialog (#2565) feat(desktop): add drag-to-reorder for community rail (#2549) fix(channels): strip leading hash prefixes from names (#2250) fix(desktop): allow skipping harness setup onboarding (#2360) Script cleanup feat(relay): make Redis pool size configurable, default 16 (#2521) Co-authored-by: Cursor <cursoragent@cursor.com> # Conflicts: # desktop/src-tauri/src/commands/profile.rs
tlongwell-block
added a commit
that referenced
this pull request
Jul 28, 2026
## Summary - Raise the relay's Postgres pool cap from the `buzz-db` default of 20 to 50 per pool, and expose `BUZZ_DB_POOL_SIZE` for per-deploy tuning - Applies to the writer pool and, when `READ_DATABASE_URL` is set, the reader pool; zero/unparsable values fall back to the default - The `buzz-db` library default is unchanged — only the relay opts into the larger cap ## Why During the 2026-07-27 18:40–19:05Z traffic burst on bb-public, per-pod PG pools pinned at 20 fleet-wide and ~380 requests failed on the 3s acquire timeout — membership checks, channel access lookups, and historical queries returning errors to users. The database was nowhere near a limit: Aurora (db.r8g.8xlarge, ~5,000 max connections) sat at 19% CPU, 201 connections (~4% of capacity), commit latency flat at 0.01ms. The 20-connection default was sized for "four relay pods against PG max_connections=100" (the comment in `buzz-db` says exactly that). Production now runs 12–15 pods against Aurora — the per-pod cap is the binding constraint, not the DB. Budget at the new default: 15 pods × (50 writer + 50 reader + 5 audit) ≈ 1,575 potential connections, ~30% of Aurora's ceiling — and actual usage stays demand-driven (`min_connections` stays 2, connections only open under load). Same shape as #2521 (`BUZZ_REDIS_POOL_SIZE`), which fixed the identical class of ceiling on the Redis side. ## Testing - `cargo test -p buzz-relay`: 762 passed, 1 failed — the lone red is `api::mesh_demo::tests::demo_join_forwarded_arm_round_trips_echo`, the known pre-existing flake; it fails identically on clean `main` at the same SHA (verified via `git stash` / rerun) - New test `db_pool_size_env_override_and_invalid_fallback` covers override, zero, and unparsable fallback - `defaults_are_valid` extended to pin the new default - `cargo clippy -p buzz-relay --all-targets -- -D warnings` and `cargo fmt --check` clean Signed-off-by: Tyler Longwell <tlongwell@block.xyz> Co-authored-by: npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz> Co-authored-by: Tyler Longwell <tlongwell@block.xyz>
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
1 participant
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.
Why
bb-public relay pods started showing Redis pool waiters today (
buzz_redis_pool_waitingpeaked at 2,buzz_redis_pool_availablemin 1) at ~190 events/s — first waiters since launch day.Root cause: we never configure the deadpool-redis pool size, so it uses deadpool's default of
CPU_COUNT * 2. On a 2-vCPU relay pod that's 4 connections, shared by rate-limit checks, presence, pub/sub publishes, NIP-98 replay guard, and cache invalidation. Confirmed live: every bb-public pod reportsbuzz_redis_pool_max = 4.What
BUZZ_REDIS_POOL_SIZEenv var (relay), default 16 when unset; zero/unparsable values fall back to the default.main.rs(the only production pool construction; test-only pools untouched)..env.exampledocuments it.Minimal by design: 16 per pod × 5 pods = 80 Redis connections vs ElastiCache's 65k ceiling — noise for the server, but 4× more headroom where the waiters showed up. No chart change needed; ops can tune per-deploy via env.
Testing
defaults_are_validasserts the 16 default.cargo test -p buzz-relay: 735 passed, 1 failed —api::mesh_demo::tests::demo_join_forwarded_arm_round_trips_echo, which fails identically on cleanorigin/mainat the same SHA (pre-existing, known flake).cargo clippy -p buzz-relay --all-targetsclean,cargo fmtclean.Observability
Watch
block.buzz_relay.buzz_redis_pool_maxflip 4 → 16 on rollout, andbuzz_redis_pool_waitingstay at 0.