feat(load-tests): add high-fidelity SLO validation scenarios #66
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
chakra-guy
force-pushed
the
ts/setup-load-testing
branch
2 times, most recently
from
f75e1ab to
fa791da
Compare
chakra-guy
force-pushed
the
ts/slo-load-testing
branch
from
c1f284e to
1b12a6f
Compare
Add three new scenarios for SLO validation using actual protocol clients: - realistic-session: Full dApp+Wallet handshake with message exchange - async-delivery: Tests historical message recovery after wallet reconnect - steady-messaging: Sustained message latency under load over time Key implementation details: - Uses MockKeyManager for lightweight crypto (CPU-efficient load generation) - Realistic timing: 5s wallet connect delay, 1s message delay - Reusable pacing utility (runWithPacing) for all scenarios - InMemoryKVStore for session management All scenarios verified against local Docker Compose with 100% success rates.
… waits before responding (simulates user reviewing request) - Each round: dApp sends → wallet waits → wallet responds → dApp receives - Response delay = message interval (e.g., 10s) - Latency measured excludes artificial delay (actual network time only) - Rounds run sequentially, no overlapping
Key changes: - Each pair starts its messaging loop immediately upon connecting - No synchronized bursts - load is naturally distributed - Both sides wait: dApp sends → wallet waits → responds → dApp waits → repeat - Message cycle takes 2 * messageInterval (e.g., 20s for 10s interval) - Pairs connect during ramp-up and start messaging right away - Metrics collected continuously with periodic snapshots
…tions The protocol needs time to synchronize internal state before message exchange can reliably work. 100ms was insufficient for production connections with ~200ms latency. 500ms provides a reliable buffer.
chakra-guy
force-pushed
the
ts/slo-load-testing
branch
from
d538873 to
8bae672
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
wenfix
approved these changes
Jan 20, 2026
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
Adds three high-fidelity load testing scenarios for SLO validation using actual protocol clients (
DappClient,WalletClient). These scenarios test the relay server from the application's perspective, not just raw WebSocket connections.New Scenarios
realistic-sessionasync-deliverysteady-messagingImplementation Details
High-Fidelity Design
DappClientandWalletClientfrom protocol librariesPerformance Optimizations
MockKeyManager: Bypasses real ECIES crypto (CPU-intensive) since the relay only sees opaque payloadsrunWithPacing()utility for consistent ramp-up behavior across scenariosNew Files
client/session-pair.ts- Session pair creation and messagingclient/key-manager.ts- Mock crypto for load testingutils/pacing.ts- Pacing utilitiesutils/kvstore.ts- In-memory KV storescenarios/realistic-session.ts,async-delivery.ts,steady-messaging.tsUsage
Realistic session: handshake + message exchange
yarn start --scenario=realistic-session --target=ws://... --connections=100 --ramp-up=10 --messages-per-session=3Async delivery: historical message recovery
yarn start --scenario=async-delivery --target=ws://... --connections=100 --ramp-up=10 --delay=30Steady messaging: sustained load over time
yarn start --scenario=steady-messaging --target=ws://... --connections=100 --ramp-up=10 --duration=120 --message-interval=5Note
Adds end-to-end scenarios using real protocol clients to validate relay performance and SLOs.
realistic-session,async-delivery,steady-messagingwith pacing and progress bars--connection-pairs,--messages-per-session,--delay,--message-interval; scenario-aware config and outputTestResultsand formatter to includehandshake,messages,recovery,steadyMessaging, latency stats, and SLO PASS/FAIL indicatorsclient/session-pair.ts(pair handshake and message exchange),client/key-manager.ts(MockKeyManager),utils/kvstore.ts,utils/pacing.tsscenarios/realistic-session.ts,async-delivery.ts,steady-messaging.ts; wiring viascenarios/index.tseciesjsinpackage.json/yarn.lockWritten by Cursor Bugbot for commit 8bae672. This will update automatically on new commits. Configure here.