Measure Ithaca RabbitMQ traffic for separate host sizing
Read-only five-minute production RabbitMQ bandwidth sample on ithaca.project-rk.com, matching MSSQL investigation. Measure bidirectional container interface counters every250ms, aggregate sequential one-second windows and attribute AMQP TCP deltas to clients. No configuration changes, restarts or payload capture. Acceptance: averages, peaks,2.5Gbps utilization and explicit latency/startup/busy-hour limitations. Verified2026-11-01T21:18:56–21:23:56 UTC,300.0005s/1200 samples. engines-mq172.18.0.12 on kamal Docker bridge; AMQP5672 has eight established engine connections, no new/closed sockets. Namespace eth0 RX10438996/TX48497781 bytes; average0.278373/1.293272Mbps; sequential1s max1.803122/6.868708Mbps;250ms max3.095610/17.371118Mbps. Zero RX/TX drops/errors. Outbound average0.0517% and250ms max0.6948% of2.5Gbps. AMQP attribution lower-bound TCP RX/TX bytes: PFE4 1953147/7247354, login5570/11531420, PFE1 2433791/7251784, PFE2 1194362/7246936, clientweb151284/1361299, PFE3 1486662/7243723, market1204151/95684, chat2723/4459325. All engine containers remained healthy; no configuration changes/restarts/payload capture. Bandwidth very comfortably fits2.5Gbps, including alongside previously measured SQL steady-state averages; SQL and MQ samples were sequential so coincident peaks not established. Latency, publisher confirms/request-response, startup/backlog recovery, busy-hour loads and sub250ms bursts remain untested. Physical wire overhead excluded.
Checklist
1 of 1 complete- Verify RabbitMQ network/client path, collect five-minute traffic sample and assess 2.5 Gbps headroom with limitations.
- Area
- Project Rubi-Ka
- Project
- engines
- Kind
- Operations
- Task ID
tsk_e3k3zwkyd7- Updated