Wir implementieren einen Service, der von vielen Nutzern gleichzeitig genutzt wird. In Spitzen können wir Zehntausende von Menschen online haben.
Ein kritischer Teil unseres Dienstes muss neu implementiert werden, und wir versuchen, über neue Wege nachzudenken. Im Moment senden wir einfache und sehr kurze / kleine AJAX-HTTP-Anfragen basierend auf Benutzerinteraktion:
Zur gleichen Zeit, in einigen Fällen (1 in 10) haben wir EventSource geöffnet, von dem wir einige Änderungen auf dem Server gelesen haben.
Die Frage ist, ob dieses Modell gut genug ist oder ob es besser ist, einen WebSocket zu öffnen und alles über WebSockets zu übergeben.
Was sollte die Entscheidung für die richtige Implementierung sein?
Es wurde festgestellt, dass diese Frage das gleiche beantwortet: WebSockets-Protokoll vs HTTP - aber ich Fragen Sie nach einem bestimmten Anwendungsfall. Die damit verbundene Frage wird eher allgemein gestellt.
- Nachteil - wenn viele Leute online sind, würden wir Tausende von Verbindungen aktiv halten
Sie können Ihren Dienst implementieren, um nach einem Timeout die Verbindung zu einem leeren Websocket zu schließen. Das ist wahrscheinlich die gleiche Art und Weise, wie EventSource für Sie arbeitet, also halten Sie nicht zu viele aktive Verbindungen. (Ähnliche Leistungsmerkmale.)
(Wenn Sie jedoch auf die automatische Wiederverbindung von EventSource durch den Browser angewiesen sind, bedeutet das Wechseln zu WebSocket, dass Sie mehr Code für die Logik der Wiederverbindung schreiben müssen.)
Normalerweise sollte WebSocket weniger Netzwerkverkehr verursachen. Wie groß der Unterschied ist, hängt davon ab, wie Ihr aktueller Service implementiert wird. Wenn Sie Ihre Logik bereits optimiert haben und mit AJAX und EventSource jede Menge Leistung verdrängen, kann die Verwendung von WebSocket eine marginale Verbesserung darstellen.