Een supportchat die in Node.js is geïmplementeerd, werkt perfect bij staging: twintig testers, onmiddellijke latentie. In productie op dezelfde VPS, 300 agenten verbonden – de server geeft aan dat er “te veel open bestanden” zijn, nginx retourneert 502 en verbindingen vallen elke 60 seconden weg omdat niemand de standaard proxy_read_timeout heeft opgemerkt.
WebSocket is niet een beetje langer HTTP. Het is een ander bronmodel: aanhoudende verbindingen, geheugen per klant, hartslagen en vaak uitzendingen die elk bericht versterken. Realtime hosten zonder plan betekent het omzetten van een productsucces in een voorspelbaar infrastructuurincident.
WebSocket versus HTTP: wat een verbinding werkelijk verbruikt
| Bron | Kort HTTP-verzoek | Open WebSocket |
|---|---|---|
| Bestandsbeschrijvingen | 1 vervolgens vrijgegeven | 1 onderhouden uren |
| App-servergeheugen | Gerecycleerde zwembadwerker | Buffer + sessiestatus |
| Verwerker | Piek voor zoekopdracht | Hartslag + vervolgberichten |
| Proxy | Staatloos, gemakkelijk | Upgrade + time-out om te configureren |
| Opschalen | Enkele horizontale | Affiniteit of pub/sub vereist |
Vuistregel: schat 50 KB tot 200 KB geheugen per verbinding, afhankelijk van de stack (Node, GB, Elixir variëren). 5.000 verbindingen × 100 KB ≈ 500 MB — vóór bedrijfscode.
Het nummer dat als eerste doodgaat is niet de CPU - het is
ulimit -nen de proxy-time-out.
Omgekeerde proxy: nginx vóór de realtime applicatie
Minimale nginx-configuratie:
locatie /ws/ {
proxy_pass http://127.0.0.1:3000;
proxy_http_versie 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Verbinding "upgrade";
proxy_set_header Host $host;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
}
Vaak vergeten punten: de globale limiet worker_connections nginx versus WebSocket-verbindingen; TLS-beëindiging bij proxy — sommige hosts beperken gelijktijdige SSL-verbindingen; HTTP/2 aan de openbare clientzijde, HTTP/1.1 Upgrade upstream.
Zie ook WebSocket timeout proxy en Nginx ou Apache.
Horizontale schaling: affiniteit versus makelaar
Optie A: Sticky-sessies. De load balancer stuurt de client naar hetzelfde knooppunt. Eenvoudig, kwetsbaar als het knooppunt valt (massale herverbinding).
Optie B — Redis pub/sub- of Socket.IO-adapter. Berichten gerouteerd tussen knooppunten; gedistribueerde verbindingen. Vereist vanaf twee of meer exemplaren.
Optie C — Beheerde service (Pusher, Ably, beheerde Mercure-hub). Complexiteit uitbesteden; kosten per bericht.
Voor een serieuze MVP verslaat optie B op twee kleine VPS een enkele grote server zonder pub/sub.
Hosting: vragen om aan de provider te stellen
Voordat u een keuze maakt, moet u zich afvragen of lange verbindingen zijn toegestaan (gedeeld, vaak geknipt), wat de limiet voor de bestandsdescriptor is, of UDP of QUIC worden gefilterd voor WebTransport, of de Layer 7 load balancer de WebSocket Upgrade ondersteunt en of anti-DDoS ten onrechte langzame verbindingen kan blokkeren.
Cloud VPS (Hetzner, OVH, Scaleway) met nginx blijft de meest voorspelbare combinatie voor zelf-gehoste WebSocket.
Hartslagen, herverbinding en waarneembaarheid
Stuur elke 30 seconden een applicatieping/pong om dode verbindingen te detecteren. Pas een exponentieel uitstel toe aan de clientzijde om te voorkomen dat de server bij het opnieuw opstarten overbelast raakt. Meet actieve verbindingen, berichten per seconde en bezorglatentie in het 99e percentiel. Plan een sierlijke stop: stopsignaal, stop accepteren, 30 seconden leeglopen.
De top: realtime schalen in verbindingen, niet in paginaweergaven
Het verkopen van “live chat” zonder maximale verbindingscijfers, proxy-time-out en pub/sub-abonnement is het verkopen van een functie die het eerste succes niet overleeft.
Beslis en ga vooruit zonder blinde vlek
Bereken eerst het maximale aantal verbindingen × geheugen en vink ulimit aan. Configureer nginx-time-outs vóór het starten. Test het opnieuw verbinden na de implementatie, niet alleen tijdens het nominale traject. Plan Redis pub/sub vóór de tweede server. Zet een dashboard op van actieve verbindingen met waarschuwing bij 80% van de drempel.
Verken VPS en cloud in de overzicht en de vergelijking.
Veelgestelde vragen
Hoeveel WebSocket-verbindingen kan een server bevatten?
Het hangt af van het geheugen per verbinding, bestandsdescriptors en nginx. Duizenden inactieve verbindingen zijn mogelijk; veel minder als elk bericht zwaar werk met zich meebrengt.
Heeft u een sticky sessie nodig achter een load balancer?
Ja, als de toestand in het procesgeheugen leeft. Gebruik anders Redis pub/sub of een speciale hub om de status tussen knooppunten te delen.
Ondersteunt gedeeld WebSocket?
Vaak gedeeltelijk of met korte time-outs (30 tot 60 seconden). Controleer de documentatie van de hostingprovider; sommige panelen verbreken lange verbindingen.
Nginx of Apache vóór Node.js WebSocket?
Nginx komt vaker voor met Upgrade-headers en proxy_read_timeout aangepast (vaak 3600 seconden of meer). Apache mod_proxy_wstunnel werkt, maar komt minder vaak voor in realtime productie.
Realtime wordt gemeten in open verbindingen – niet in unieke bezoekers van de afgelopen maand.