nodefony-multipod-bench

Provisions a multi-pod Redis backplane bench to test cross-pod fan-out, injection defense, and latency.

Updated Dec 19, 2023
One-click install
npx skills add https://github.com/nodefony/nodefony-core --skill nodefony-multipod-bench-nodefony
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: nodefony-multipod-bench
Source: https://github.com/nodefony/nodefony-core/tree/main/.claude/skills/nodefony-multipod-bench
Command: npx skills add https://github.com/nodefony/nodefony-core --skill nodefony-multipod-bench-nodefony

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Cluster behaviors of a realtime backplane cannot be proven by unit tests with a mocked hub. This Skill stands up a real multi-pod environment — several Nodefony applications sharing one Redis bus — to verify cross-pod fan-out, application isolation, bus injection resistance, and end-to-end latency and throughput. ## Core Features & Use Cases - Idempotent bench provisioning: setup.sh starts a Redis container, generates two applications linked to the local framework, installs a bench controller, and configures a shared backplane namespace; run.sh starts three pods (two sealed peers plus one unsealed control pod). - Attack matrix and measurement scripts: forge sealed attacker envelopes, inject raw Redis PUBLISH messages, and measure pure latency, burst throughput, publication cost, connection soak tiers, and memory peaks. - Database resilience benches: dedicated scripts test pod survival during database outages, readiness probe behavior on schema drift, and data persistence across graceful restarts. - Use Case: Verify that a message published on pod A1 reaches a WebSocket client on pod A2, that an unsealed injection is rejected by sealed pods but received by the unprotected control pod, and capture p50/p95/p99 latency across the bus. ## Quick Start Ask the AI to set up the multi-pod bench and run the cross-pod fan-out and injection tests using the nodefony-multipod-bench skill.

Frequently Asked Questions about nodefony-multipod-bench

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test cross-pod realtime fan-out with a Redis backplane?

Run setup.sh to provision Redis and two linked applications, then run.sh to start three pods. Publish via curl on one pod's /api/chat/say route and listen with listen.mjs on another pod to confirm the message traverses the bus.

How can I test backplane injection attacks against a Redis bus?

Use redis-cli PUBLISH to inject unsealed messages and forge.mjs to craft HMAC-sealed attacker envelopes. Sealed pods must reject both, while the unsealed control pod must receive them as a negative control proving the defense actually works.

Why does my multi-pod benchmark show high latency when everything works?

Burst publishing saturates the delivery queue, so you measure backlog rather than transport time. Use latency.mjs with spaced messages for pure path latency and bench.mjs only for throughput, taking the median of several runs.

Why does starting a second pod kill the first one?

The development supervisor is single-instance per application root, so a second development launch evicts the first. Run pods in production mode, which has no supervisor and matches real deployment behavior.

Can this bench test database outage and readiness probe behavior?

Yes. db-outage-pod.mjs verifies pods survive a database stop and keep serving, db-readiness-pod.mjs checks /readyz responses to schema drift, and db-persistance-pod.mjs confirms data survives graceful restarts.

When should I not use the multi-pod bench?

Skip it for provider-internal logic like per-channel timers, which belongs in unit tests, and for single-pod connection or RPS limits, which belong to a single-pod load test. The bench only proves behaviors requiring a real shared bus.