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
from
59062fd to
f75e1ab
Compare
…testing - DigitalOcean droplet provisioning (create/destroy) - SSH-based command execution on droplets - Parallel execution with progress tracking - Results collection via SFTP - Background execution for long-running tests - Results aggregation across multiple droplets
- Fix latency aggregation bug (allLatencies was never populated) - Rename latency → connectTime to match scaffolding PR - Use corepack for Yarn installation instead of npm install -g yarn - Fix SSH exit code null handling (assume failure if no exit code) - Add concurrency limit (5) for droplet creation to avoid rate limits - Add aggregator input validation for required fields - Extract DROPLET_HOURLY_COST constant
- Add branch name validation to prevent shell injection (droplet.ts, infra.ts) - Add regex escaping for name prefix to prevent incorrect droplet matching - Add shell single-quote escaping for file paths in wait command - Add NaN validation for timeout/interval to prevent infinite loops - Add timeout to SFTP download to prevent hanging indefinitely
chakra-guy
force-pushed
the
ts/setup-load-testing
branch
from
f75e1ab to
fa791da
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.
chakra-guy
force-pushed
the
ts/slo-load-testing
branch
from
c1f284e to
1b12a6f
Compare
… 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.
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=5