Solid Cable: scale
This course looks at how Solid Cable behaves under load, using the benchmark published in the solid_cable 4.0.2 README and the gem's own source. It compares round-trip times against Redis and against Action Cable's postgresql adapter, which uses LISTEN/NOTIFY and caps payloads just under 8 kB. It then covers polling_interval, the setting that changes latency, and autotrim with scheduled trimming. Later lessons look at connects_to and this app's shared production database, the cost of more server processes, and the cases where a different adapter fits better.
What you'll learn
- ✓How to read the gem's k6 benchmark: virtual users, average RTT and p(90) and p(95)
- ✓Why Solid Cable's polling differs from Redis pub/sub and PostgreSQL LISTEN/NOTIFY
- ✓How polling_interval trades poll queries for lower delivery latency
- ✓How autotrim runs on each broadcast and how to schedule TrimJob instead
- ✓How connects_to, process count, use_skip_locked and reconnect_attempts affect database load
- ✓When a configuration change stops being enough and another adapter fits better
Reading the numbers: Solid Cable against Redis under load
The mid-level course "Solid Cable: scaling WebSockets" looked at this app's solid_cable_messages table in development, where one browser tab over a few sessions had written every row. That never had to answer a harder question: what happens when it isn't one tab but a thousand?
Read the full lesson free →Curriculum
7 lessonsReading the numbers: Solid Cable against Redis under load
Reads the gem's published k6 benchmark, where Solid Cable on PostgreSQL trails Redis more as virtual users increase.
The adapter next door: PostgreSQL's own LISTEN/NOTIFY
Compares Solid Cable with Action Cable's postgresql adapter, which uses LISTEN/NOTIFY and limits payloads to just under 8 kB.
polling_interval: the only knob that touches latency
Explains polling_interval, the only setting that changes delivery latency, and the extra poll queries a shorter interval costs.
autotrim under pressure: turning off the lottery
Shows how autotrim runs inside each broadcast and why autotrim: false makes a scheduled TrimJob always trim.
One database or two: this app's own answer
Examines connects_to and this app's database.yml, where production keeps cable messages in the same database as the app.
More processes, more pollers: horizontal scaling's real cost
Explains how each server process adds its own poller, plus the roles of use_skip_locked and reconnect_attempts.
Putting it together: when Solid Cable stops being enough
Orders the available levers, names where configuration stops helping, and closes with a challenge modelling TrimJob's trim decision.