Guia Completo de Infraestrutura para Aplicações em Tempo Real: Como Hospedar e Escalar WebSockets, gRPC e SSE em Servidores VPS e VDS
No cenário atual do desenvolvimento de software, a interatividade instantânea deixou de ser um diferencial e tornou-se um requisito básico. Seja para plataformas de trading financeiro, chats corporativos, jogos multiplayer, ferramentas colaborativas como o Figma ou sistemas de rastreamento de frotas em tempo real, a comunicação bidirecional de baixa latência é o coração dessas aplicações. No entanto, mover uma aplicação tradicional baseada em requisições HTTP REST (Stateless) para um modelo persistente, orientado a eventos em tempo real, impõe desafios gigantescos à infraestrutura de hospedagem.
Enquanto uma requisição HTTP tradicional abre uma conexão, entrega o conteúdo e fecha o canal imediatamente, aplicações de tempo real mantêm milhares — ou milhões — de conexões TCP abertas simultaneamente por longos períodos. Esse comportamento exige um design de infraestrutura completamente diferente. Hospedagens compartilhadas tradicionais simplesmente colapsam sob essa carga devido a limites rígidos de processos, memória e conexões simultâneas.
Neste guia definitivo, exploraremos como arquitetar, configurar, otimizar e escalar infraestruturas para aplicações em tempo real utilizando os servidores VPS Performance e VDS (Servidores Dedicados Virtuais) da CoelhoVPS. Você aprenderá do tuning do kernel do Linux à configuração avançada de proxies reversos e estratégias de escalabilidade horizontal.
1. Entendendo as Tecnologias de Tempo Real: WebSockets, SSE e gRPC
Antes de ajustar a infraestrutura, precisamos compreender as demandas específicas de cada protocolo de comunicação em tempo real. Cada um deles interage de forma única com a CPU, memória e rede do seu servidor.
WebSockets
O protocolo WebSocket (padronizado pela RFC 6455) permite a comunicação bidirecional full-duplex sobre uma única conexão TCP de longa duração. Ele começa com um handshake HTTP tradicional que solicita um "upgrade" de protocolo. Uma vez estabelecido, o canal permanece aberto para que tanto o cliente quanto o servidor enviem dados a qualquer momento.
- Ideal para: Chats em tempo real, jogos multiplayer, dashboards interativos bidirecionais.
- Desafio de Infraestrutura: Consumo persistente de memória RAM por conexão (overhead de socket) e necessidade de balanceamento de carga inteligente (Sticky Sessions).
Server-Sent Events (SSE)
O SSE é um padrão baseado em HTTP unilateral (unidirecional), onde apenas o servidor envia atualizações contínuas para o cliente por meio de uma conexão HTTP persistente (usando o cabeçalho text/event-stream).
- Ideal para: Feeds de notícias, cotações de ações unidirecionais, atualizações de status de entrega, notificações push.
- Desafio de Infraestrutura: Limites de conexões simultâneas por domínio em navegadores antigos (HTTP/1.1 limita a 6 conexões por domínio, exigindo HTTP/2 ou HTTP/3 para multiplexação).
gRPC (Google Remote Procedure Call)
Baseado em HTTP/2 e Protocol Buffers (protobuf), o gRPC é um framework de alto desempenho focado na comunicação entre microsserviços e APIs móveis. Ele suporta streaming unidirecional e bidirecional nativamente.
- Ideal para: Comunicação de baixíssima latência entre microsserviços internos, transmissão de grandes volumes de dados binários serializados.
- Desafio de Infraestrutura: Requer suporte nativo a HTTP/2 fim a fim e balanceamento de carga complexo na camada L7 (aplicação), pois as conexões HTTP/2 TCP são persistentes e reutilizadas.
2. O Gargalo Oculto: Por que a Hospedagem Tradicional Falha no Tempo Real?
A maioria dos servidores de hospedagem compartilhada ou VPS de baixa qualidade é configurada com o foco em throughput (vazão) de requisições curtas. Elas usam servidores web como o Apache no modo prefork, onde cada conexão ativa consome um processo ou thread inteira do sistema operacional.
Imagine um cenário onde 5.000 usuários acessam simultaneamente uma aplicação de chat. Em um servidor tradicional:
- Esgotamento de Threads/Processos: O sistema tentará alocar 5.000 threads. Como cada thread consome entre 2MB e 8MB de stack size do sistema, o servidor esgotará rapidamente a memória RAM física, acionando o OOM (Out Of Memory) Killer do Linux, derrubando o banco de dados e a aplicação.
- Limites de File Descriptors (Descritores de Arquivos): No Linux, "tudo é um arquivo". Cada conexão socket TCP aberta consome um file descriptor. O limite padrão para usuários comuns costuma ser de 1024. Ao atingir o 1025º usuário, a aplicação começará a rejeitar novas conexões com o erro
EMFILE: too many open files. - Estrangulamento de CPU por Context Switching: Se o processador precisar alternar entre milhares de threads ativas para processar pequenos pacotes de dados, ele gastará mais ciclos de CPU gerenciando essa alternância (context switching) do que executando o código da aplicação de fato.
Para resolver esses problemas, precisamos de uma infraestrutura baseada em recursos dedicados de CPU e armazenamento NVMe ultrarrápido, como os planos VPS Performance ou VDS da CoelhoVPS, combinados com uma severa otimização do sistema operacional Linux.
3. Preparando a Infraestrutura: Escolhendo Entre VPS Performance, VDS e VPS Storage
Antes de iniciarmos a configuração técnica, é crucial entender qual tipo de servidor se adapta melhor à sua arquitetura de tempo real:
| Tipo de Servidor | Perfil de Recurso | Melhor Caso de Uso em Tempo Real |
|---|---|---|
| VPS Performance (CoelhoVPS) | Processadores de alta frequência, discos NVMe de altíssima velocidade de leitura/escrita, recursos isolados por virtualização KVM. | Servidores de Websocket Hubs (Node.js/Socket.io, Go, Elixir), APIs REST de suporte, microsserviços com alto tráfego I/O. |
| VDS (Virtual Dedicated Server) | Núcleos de CPU físicos dedicados exclusivamente ao seu servidor (sem overcommit), RAM totalmente dedicada. | Aplicações críticas que exigem latência consistente de sub-milissegundos, servidores gRPC com alto paralelismo e processamento de criptografia TLS intensa. |
| VPS Storage (CoelhoVPS) | Grande capacidade de armazenamento, excelente custo-benefício para leitura/escrita sequencial. | Servidores de logs centralizados, histórico de chat para auditoria de conformidade, brokers de mensageria com persistência pesada em disco (ex: Apache Kafka/RabbitMQ). |
Para a maioria dos cenários de produção de alta escala, recomendamos implantar um VDS para o processamento principal de conexões ativas (onde a CPU dedicada garante que nenhuma outra VPS "vizinha" roube ciclos de processamento essenciais para manter a latência baixa), integrado com instâncias VPS Performance atuando como nós secundários de distribuição.
4. Otimização Extrema do Kernel Linux (Sysctl Tuning)
Por padrão, sistemas operacionais Linux corporativos (como Ubuntu Server ou Rocky Linux) vêm otimizados para servidores web tradicionais. Para suportar dezenas de milhares de conexões persistentes simultâneas, precisamos aplicar ajustes profundos no arquivo /etc/sysctl.conf.
Abaixo, apresentamos as configurações recomendadas para servidores focados em tempo real na CoelhoVPS. Acesse sua instância via SSH como root e edite o arquivo:
sudo nano /etc/sysctl.conf
Adicione as seguintes linhas ao final do arquivo com as devidas explicações técnicas de cada parâmetro:
# --- OTIMIZAÇÃO DA PILHA TCP/IP PARA ALTA ESCALA REAL-TIME --- # Aumenta o limite máximo de conexões pendentes que podem ser enfileiradas no sistema net.core.somaxconn = 65535 # Aumenta o número máximo de pacotes na fila de entrada da placa de rede net.core.netdev_max_backlog = 65536 # Define o limite máximo de sockets órfãos (sem associação a descritores de arquivo) net.ipv4.tcp_max_orphans = 262144 # Evita o esgotamento de portas locais ao aumentar a faixa de portas efêmeras disponíveis net.ipv4.ip_local_port_range = 1024 65535 # Habilita a reutilização de sockets TIME_WAIT para novas conexões (essencial para reuso de conexões rápidas) net.ipv4.tcp_tw_reuse = 1 # Ajusta o tempo que uma conexão permanece no estado FIN-WAIT-2 antes de ser fechada pelo kernel net.ipv4.tcp_fin_timeout = 15 # Ativa os pacotes TCP Keepalive para verificar se as conexões inativas ainda estão vivas net.ipv4.tcp_keepalive_time = 300 net.ipv4.tcp_keepalive_intvl = 15 net.ipv4.tcp_keepalive_probes = 5 # Define os buffers de memória TCP mínimo, padrão e máximo (em bytes) # Otimizado para permitir que conexões consumam menos memória inicial, escalando apenas sob necessidade net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 # Habilita o algoritmo BBR de controle de congestionamento de rede (desenvolvido pelo Google) # Extremamente eficaz para reduzir a latência em redes com alguma perda de pacotes net.core.default_qdisc = fq net.ipv4.tcp_congestion_control = bbr # Aumenta o limite máximo de tabelas de rastreamento de conexões (conntrack) net.netfilter.ip_conntrack_max = 1048576 net.nf_conntrack_max = 1048576
Salve e feche o arquivo. Para aplicar todas as alterações imediatamente sem reiniciar o servidor, execute:
sudo sysctl -p
Ajustando os Limites de Descritores de Arquivos (Limits)
Agora que o kernel do Linux está pronto para processar as conexões, precisamos garantir que o sistema operacional permita que os processos individuais da aplicação abram essa quantidade colossal de sockets. Edite o arquivo de limites de segurança:
sudo nano /etc/security/limits.conf
Adicione as seguintes linhas ao final do arquivo, substituindo root e www-data pelo usuário que executa a sua aplicação de tempo real:
* soft nofile 1048576 * hard nofile 1048576 root soft nofile 1048576 root hard nofile 1048576 www-data soft nofile 1048576 www-data hard nofile 1048576
Se você utiliza o systemd para gerenciar o serviço da sua aplicação (o que é altamente recomendado), as configurações acima podem ser ignoradas pelo próprio systemd. Para garantir que seu serviço tenha os limites corretos, adicione a diretiva LimitNOFILE diretamente no arquivo de unidade do seu serviço (/etc/systemd/system/sua-aplicacao.service):
[Service] Type=simple ExecStart=/usr/bin/node /var/www/sua-aplicacao/index.js Restart=always LimitNOFILE=1048576 LimitNPROC=1048576
Recarregue o daemon do systemd e reinicie o seu serviço:
sudo systemctl daemon-reload sudo systemctl restart sua-aplicacao
5. Configuração Avançada de Proxy Reverso: Nginx e HAProxy
Expor sua aplicação Node.js, Go ou Python diretamente para a internet pública não é uma boa prática de segurança nem de performance. Um proxy reverso robusto deve interceptar o tráfego externo, lidar com o handshake TLS (SSL), mitigar ataques volumétricos básicos e repassar conexões limpas para a sua aplicação via redes internas em localhost.
Otimizando o Nginx para WebSockets e HTTP/2 (gRPC)
O Nginx é o proxy reverso mais popular, mas sua configuração padrão falha miseravelmente ao tentar manter conexões persistentes abertas. Abaixo está uma configuração otimizada de bloco de servidor Nginx para lidar com WebSockets e gRPC simultaneamente em um servidor VPS Performance:
# Configuração global no /etc/nginx/nginx.conf
user www-data;
worker_processes auto; # Define automaticamente de acordo com os núcleos de CPU da sua VPS/VDS
worker_rlimit_nofile 1048576; # Sincroniza o limite de arquivos do Nginx com o do OS
events {
worker_connections 50000; # Permite que cada worker processe até 50 mil conexões simultâneas
use epoll; # Método de processamento de conexões assíncronas de alto desempenho para Linux
multi_accept on; # Aceita novas conexões o mais rápido possível
}
http {
# Configurações de timeout para conexões em tempo real
keepalive_timeout 300s; # Mantém conexões keepalive abertas por mais tempo
keepalive_requests 100000; # Permite mais requisições por conexão persistente
# Mapeamento para upgrade de cabeçalhos do WebSocket
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
# Servidor de WebSocket / HTTP normal
server {
listen 443 ssl http2;
server_name websocket.seu-dominio.com;
ssl_certificate /etc/letsencrypt/live/seu-dominio/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/seu-dominio/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
location / {
proxy_pass http://127.0.0.1:8080;
# Cabeçalhos cruciais para Upgrade de WebSocket
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
# Preservar o IP real do cliente
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# Desabilitar buffering para evitar latência induzida por cache no proxy
proxy_buffering off;
proxy_read_timeout 86400s; # Evita que o Nginx derrube a conexão WebSocket inativa (24 horas)
proxy_send_timeout 86400s;
}
}
# Servidor gRPC (Comunicações internas de alta performance)
server {
listen 50051 ssl http2; # gRPC exige estritamente HTTP/2
server_name grpc.seu-dominio.com;
ssl_certificate /etc/letsencrypt/live/seu-dominio/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/seu-dominio/privkey.pem;
location / {
grpc_pass grpc://127.0.0.1:50052; # Direciona para o microsserviço gRPC local
# Configuração de timeouts específicos para streams gRPC
grpc_read_timeout 31536000s; # Mantém stream ativo por longo prazo
grpc_send_timeout 31536000s;
}
}
}
HAProxy: O Campeão Supremo para WebSockets e gRPC
Se você está construindo uma infraestrutura que precisa passar de 100.000 conexões WebSocket simultâneas, o HAProxy é frequentemente superior ao Nginx. Ele possui um gerenciamento de memória muito mais refinado e ferramentas avançadas de inspeção de tráfego em tempo real.
Aqui está uma configuração de balanceamento de carga para múltiplas VPS de aplicação rodando atrás de um nó central HAProxy hospedado em um VDS da CoelhoVPS:
global
maxconn 250000 # Limite total de conexões globais
log /dev/log local0
user haproxy
group haproxy
defaults
log global
mode http
option httplog
option dontlognull
retries 3
timeout connect 5s
timeout client 3h # Timeout de cliente longo para conexões WebSocket persistentes
timeout server 3h # Timeout de servidor correspondente
frontend ws_incoming
bind *:443 ssl crt /etc/ssl/private/seu-dominio.pem alpn h2,http/1.1
maxconn 200000
# Roteamento baseado no protocolo
acl is_websocket hdr(Upgrade) -i WebSocket
acl is_grpc ssl_fc_alpn -i h2
use_backend grpc_servers if is_grpc
use_backend ws_servers if is_websocket
default_backend standard_web_servers
backend ws_servers
balance roundrobin
option http-server-close
option forceclose
# Habilita sessões persistentes via cookie para garantir que o cliente WebSocket permaneça no mesmo nó
cookie SERVERID insert indirect nocache
server node1 10.0.0.10:8080 cookie node1 check maxconn 50000
server node2 10.0.0.11:8080 cookie node2 check maxconn 50000
backend grpc_servers
balance roundrobin
# gRPC exige HTTP/2 fim a fim
server grpc1 10.0.0.10:50052 check proto h2
server grpc2 10.0.0.11:50052 check proto h2
6. Estratégias de Escalabilidade Horizontal: Sincronizando o Estado entre Múltiplas VPS
Por mais potente que seja a sua VPS ou VDS, um único servidor sempre terá limites físicos. Quando sua aplicação de tempo real cresce, você precisa adicionar mais instâncias de servidores (escalabilidade horizontal). No entanto, isso traz um problema de arquitetura clássico:
Se o Usuário A estiver conectado via WebSocket na VPS #1 e o Usuário B estiver conectado na VPS #2, como eles se comunicam no mesmo chat em tempo real?
Para resolver este desafio, precisamos introduzir uma camada de Pub/Sub (Publish/Subscribe) centralizada. As abordagens mais consolidadas e fáceis de gerenciar no ecossistema da CoelhoVPS são:
Opção A: Redis Pub/Sub
O Redis é incrivelmente rápido e mantém todos os dados na RAM. Quando um servidor recebe uma mensagem de um cliente, ele publica essa mensagem em um "canal" do Redis. Todas as outras instâncias VPS assinam esse mesmo canal e repassam a mensagem para os seus respectivos clientes locais.
Para garantir que o Redis não gargale sob alta carga, hospede-o em uma VPS Performance separada, garantindo acesso ultraveloz via rede privada local à sua aplicação.
Opção B: NATS.io (Recomendado para Microsserviços)
NATS é um sistema de mensageria open-source focado em alta performance e simplicidade, escrito em Go. Diferente do Redis, o NATS foi projetado especificamente para atuar como um barramento de mensagens distribuído e escalável.
- Vantagem: Suporta clustering nativo de forma extremamente leve, sem exigir dependências complexas.
- Armazenamento de Histórico: Utilizando o recurso JetStream do NATS em uma VPS Storage, você pode armazenar de forma persistente todo o fluxo de eventos de tempo real sem comprometer a performance de RAM dos servidores principais.
7. Guia Prático: Criando e Configurando um Cluster WebSocket Resiliente
Vamos construir um laboratório prático. Implementaremos um servidor de WebSocket em Node.js utilizando o ecossistema Socket.io integrado ao Redis para comunicação multi-servidor.
Passo 1: provisionamento do Ambiente
- Crie 2 instâncias de VPS Performance para a aplicação (App-Node-1 e App-Node-2).
- Crie 1 instância de VPS Performance para o banco Redis (Redis-Master).
Passo 2: Configurando o Servidor Redis
Acesse a VPS do Redis via SSH e instale o Redis Server:
sudo apt update sudo apt install redis-server -y
Edite o arquivo /etc/redis/redis.conf para permitir conexões da sua rede privada de VPS:
# Procure pela linha 'bind' e altere para: bind 0.0.0.0 # Configure uma senha forte requirepass MinhaSenhaUltraSeguraParaORedis # Desative comandos perigosos em produção rename-command FLUSHALL "" rename-command FLUSHDB ""
Reinicie o serviço do Redis:
sudo systemctl restart redis-server
Passo 3: Criando o Código da Aplicação Node.js
Nas duas VPS de aplicação (App-Node-1 e App-Node-2), instale o Node.js v20+ e configure o projeto:
mkdir /var/www/realtime-app cd /var/www/realtime-app npm init -y npm install express socket.io @socket.io/redis-adapter redis
Crie o arquivo index.js com o seguinte código resiliente de clusterização:
const express = require('express');
const { createServer } = require('http');
const { Server } = require('socket.io');
const { createClient } = require('redis');
const { createAdapter } = require('@socket.io/redis-adapter');
const PORT = process.env.PORT || 8080;
const app = express();
const httpServer = createServer(app);
// Configuração do Cliente Redis de Pub/Sub
const redisUrl = 'redis://:MinhaSenhaUltraSeguraParaORedis@IP_DA_VPS_REDIS:6379';
const pubClient = createClient({ url: redisUrl });
const subClient = pubClient.duplicate();
const io = new Server(httpServer, {
cors: {
origin: "*",
methods: ["GET", "POST"]
},
// Otimizações de ping de conexão do Socket.io para detectar desconexões rápidas
pingTimeout: 10000,
pingInterval: 5000
});
// Inicialização do Adapter de Sincronismo entre Servidores
Promise.all([pubClient.connect(), subClient.connect()]).then(() => {
io.adapter(createAdapter(pubClient, subClient));
console.log('Conectado com sucesso ao cluster Redis Pub/Sub!');
// Iniciar o servidor HTTP após conectar ao Redis
httpServer.listen(PORT, () => {
console.log(`Servidor rodando na porta ${PORT}`);
});
}).catch(err => {
console.error('Erro ao conectar ao Redis:', err);
process.exit(1);
});
// Lógica de manipulação de conexões WebSockets
io.on('connection', (socket) => {
const serverInstance = `VPS-Node-Port-${PORT}`;
console.log(`Cliente conectado [ID: ${socket.id}] no servidor ${serverInstance}`);
// Escuta mensagem de chat enviada pelo cliente
socket.on('chat_message', (data) => {
console.log(`[Mensagem Recebida via ${serverInstance}]:`, data);
// O adapter do Redis garante que esta mensagem seja propagada para TODOS os clientes
// em TODOS os servidores do cluster web simultaneamente.
io.emit('chat_message_broadcast', {
user: data.user,
message: data.message,
sent_via: serverInstance
});
});
socket.on('disconnect', () => {
console.log(`Cliente desconectado [ID: ${socket.id}]`);
});
});
Execute o serviço em segundo plano usando um gerenciador de processos como o PM2, configurando-o para iniciar junto com o sistema operacional:
sudo npm install -g pm2 pm2 start index.js --name "realtime-node-service" pm2 startup pm2 save
8. Segurança Absoluta em Tempo Real: Mitigando Ataques Volumétricos
Aplicações baseadas em WebSockets e gRPC são alvos frequentes de ataques de negação de serviço (DDoS) altamente especializados, como o WebSocket Connection Starvation. Nesse tipo de ataque, o invasor tenta abrir milhares de conexões legítimas de WebSocket de forma muito lenta, mantendo-as abertas infinitamente para exaurir os recursos de file descriptors e threads da sua VPS.
Para proteger sua infraestrutura na CoelhoVPS, adote as seguintes práticas recomendadas:
1. Limitação de Conexões por IP (Rate Limiting) no Nginx
Previna ataques de brute-force e inundação de conexões estabelecendo limites diretamente no proxy reverso:
# No bloco http do nginx.conf
limit_conn_zone $binary_remote_addr zone=addr_limit:10m;
server {
...
location / {
# Permite no máximo 50 conexões WebSocket ativas por IP de origem único
limit_conn addr_limit 50;
...
}
}
2. Autenticação Rápida no Handshake
Nunca permita que conexões de WebSocket sejam totalmente estabelecidas sem autenticação prévia. O handshake HTTP inicial (Upgrade) deve conter um token JWT curto e seguro. Se o token for inválido, rejeite a conexão imediatamente no nível HTTP com status 401, impedindo que o fluxo consuma recursos de socket TCP persistentes na aplicação.
3. Desconexão Ativa de Clientes Inativos (Idle Timeout)
Sistemas em tempo real devem enviar pings regulares (heartbeats) para validar se o cliente está realmente ativo. Configure sua aplicação para fechar ativamente qualquer socket que não responda a 3 pings consecutivos (geralmente isso é tratado de forma nativa pela biblioteca Socket.io com os parâmetros pingInterval e pingTimeout configurados no Passo 7).
9. Como Testar a Carga e Monitorar Conexões em Produção
Antes de colocar sua aplicação de tempo real no ar, você deve simular milhares de conexões concorrentes para certificar-se de que todo o seu tuning de Kernel, limites de arquivos e configurações de proxy estão funcionando conforme o esperado.
Executando Testes de Carga com K6
O Grafana K6 é um dos melhores utilitários modernos para testes de performance e suporta WebSockets e gRPC de forma nativa.
Crie um script de teste simples em JavaScript para o K6 (websocket_test.js):
import ws from 'k6/ws';
import { check } from 'k6';
export const options = {
stages: [
{ duration: '1m', target: 5000 }, // Sobe para 5.000 conexões abertas em 1 minuto
{ duration: '5m', target: 5000 }, // Mantém as 5.000 conexões ativas por 5 minutos
{ duration: '1m', target: 0 }, // Desconecta suavemente todos os usuários
],
};
export default function () {
const url = 'wss://websocket.seu-dominio.com/socket.io/?EIO=4&transport=websocket';
const res = ws.connect(url, null, function (socket) {
socket.on('open', () => {
// Envia uma mensagem inicial simulando atividade do usuário
socket.send('42["chat_message", {"user": "User-Test", "message": "Olá Mundo!"}]');
// Envia pings periódicos para simular o comportamento de keepalive
socket.setInterval(() => {
socket.send('2'); // Ping no protocolo Engine.io do Socket.io
}, 25000);
});
socket.on('close', () => console.log('Desconectado do servidor'));
socket.on('error', (e) => console.error('Erro na Conexão:', e.error()));
});
check(res, { 'Status é 101': (r) => r && r.status === 101 });
}
Execute o teste de carga a partir de uma VPS de testes separada para não interferir na banda de rede dos servidores principais:
k6 run websocket_test.js
Monitorando Métricas Vitais de Rede no Servidor
Durante a execução do teste de carga, acesse a sua VPS de aplicação via SSH e use os seguintes utilitários para acompanhar em tempo real a saúde do seu servidor:
- Visualizar conexões TCP ativas por estado:
ss -s
Este comando exibe um resumo rápido do total de sockets abertos e quantas conexões estão ativas no estado ESTABLISHED. - Verificar uso de RAM e CPU detalhado por thread:
htop
Acompanhe o consumo total e se há picos irregulares em threads individuais da sua aplicação. - Verificar a taxa de IOPS de escrita e leitura de disco:
iostat -x 1 10
Essencial se você estiver usando persistência pesada com brokers de mensagens locais na VPS.
Conclusão: A Base de Sucesso para seu Sistema em Tempo Real
Desenvolver sistemas em tempo real é uma arte complexa, mas hospedar e escalar essa estrutura com confiança torna-se um processo fluído e seguro quando escolhemos a base de infraestrutura correta e aplicamos as boas práticas adequadas de tuning do sistema operacional.
Ao optar pelos planos de infraestrutura de alta performance da CoelhoVPS, você garante:
- VPS Performance com processadores potentes e SSDs NVMe de última geração para entrega instantânea de dados;
- VDS (Virtual Dedicated Servers) com núcleos físicos dedicados para eliminar problemas de ruidosos vizinhos (noisy neighbors) e manter a latência de rede estável e previsível;
- VPS Storage robustos para arquivar seus históricos de chat e logs de auditoria pesados de forma ultra-econômica.
Não permita que gargalos de infraestrutura e hospedagens limitadas comprometam a experiência em tempo real dos seus usuários. Aplique as configurações deste manual e prepare-se para ver sua infraestrutura suportar dezenas de milhares de conexões simultâneas com extrema facilidade.