Solid Cable: escala
O curso examina como o Solid Cable se comporta sob carga, a partir do benchmark publicado no README do solid_cable 4.0.2 e do código da própria gem. Ele compara o tempo de ida e volta com o Redis e com o adaptador postgresql do Action Cable, que usa LISTEN/NOTIFY e limita o payload a pouco menos de 8 kB. Depois trata do polling_interval, a configuração que mexe na latência, e do autotrim com limpeza agendada. As últimas aulas olham o connects_to, o banco compartilhado em produção, o custo de mais processos e os casos em que outro adaptador serve melhor.
O que você vai aprender
- ✓Como ler o benchmark da gem feito com k6: usuários virtuais, RTT médio, p(90) e p(95)
- ✓Por que a consulta periódica do Solid Cable difere do pub/sub do Redis e do LISTEN/NOTIFY do PostgreSQL
- ✓Como o polling_interval troca queries de consulta por menor latência de entrega
- ✓Como o autotrim roda a cada broadcast e como agendar o TrimJob no lugar dele
- ✓Como connects_to, número de processos, use_skip_locked e reconnect_attempts afetam a carga no banco
- ✓Quando uma mudança de configuração deixa de bastar e outro adaptador serve melhor
Lendo os números: Solid Cable contra Redis sob carga
O curso de nível Pleno "Solid Cable: escalando WebSockets" examinou a tabela solid_cable_messages desta aplicação em desenvolvimento. Ali, uma única aba do navegador, ao longo de algumas sessões, tinha escrito todas as linhas. Isso nunca precisou responder a uma pergunta mais difícil: o que…
Ler a aula completa grátis →Currículo
7 aulasLendo os números: Solid Cable contra Redis sob carga
Lê o benchmark publicado da gem, em que o Solid Cable no PostgreSQL fica mais atrás do Redis conforme os VUs crescem.
O adaptador vizinho: o próprio LISTEN/NOTIFY do PostgreSQL
Compara o Solid Cable com o adaptador postgresql do Action Cable, que usa LISTEN/NOTIFY e limita payloads a quase 8 kB.
polling_interval: a única configuração que toca a latência
Explica o polling_interval, a única configuração que muda a latência de entrega, e as queries extras de um intervalo menor.
autotrim sob pressão: desligando a loteria
Mostra como o autotrim roda dentro de cada broadcast e por que autotrim: false faz um TrimJob agendado sempre limpar.
Um banco ou dois: a própria resposta desta aplicação
Examina o connects_to e o database.yml da aplicação, em que produção guarda as mensagens do cable no banco principal.
Mais processos, mais pollers: o custo real da escala horizontal
Explica como cada processo do servidor acrescenta o próprio listener, e o papel do use_skip_locked e do reconnect_attempts.
Juntando tudo: quando o Solid Cable deixa de ser suficiente
Ordena as alavancas disponíveis, aponta onde a configuração deixa de ajudar e termina com um desafio sobre a decisão do TrimJob.