Ein wichtiger Punkt, der hier beachtet werden sollte, ist, dass „Chat“-Implementierungen in der Regel den eigentlichen Inhalt an die Abonnenten broadcasten.
In Discourse haben wir eine ziemlich komplexe Pipeline, die eine naive Implementierung komplex macht und zu einem hohen Datenaufkommen führt.
- Ein Benutzer antwortet
- Alle Benutzer, die das Thema ansehen, erfahren per Broadcast, dass neuer Inhalt vorhanden ist
- Alle Benutzer fragen den Server nach dem Beitraginhalt ab (100 Zuschauer = 100 Anfragen)
- Wir laden Bilder herunter und optimieren sie
- Alle Benutzer, die das Thema ansehen, erfahren per Broadcast, dass neuer Inhalt vorhanden ist
- Alle Benutzer fragen den Server nach dem Beitraginhalt ab (100 Zuschauer = 100 Anfragen)
(Wir haben verschiedene Optimierungen, Ratenbegrenzungen, Wiederholungsversuche usw., aber das ist der Kern)
Alle diese Anfragen müssen durch unsere Sicherheitspipeline laufen, um sicherzustellen, dass der Benutzer die Berechtigung hat, den Beitrag zu sehen, und so weiter.
Wenn der Inhalt eher kurz wäre und wir herausfinden könnten, wie wir die Sicherheit für die „schnelle Spur“ leichter gestalten können, könnten wir die Chat-Nachrichten per Broadcast verteilen. Das würde zu einer deutlich besseren Leistung führen; wir könnten mit diesem Design wahrscheinlich 10.000 Benutzer auf einem einzigen kleinen DigitalOcean-Droplet mit 2 GB RAM handhaben.
Sicherheit ist sehr komplex. Auch das Caching ist komplex aufgrund von Problemen mit der Cache-Invalidierung.
Also, ja, wir beschäftigen uns absolut mit diesem Problem. Aber so wie es derzeit aussieht …
Viele angemeldete Zuschauer in einem Thema + viel neuer Inhalt in einem Thema = teure Serverrechnungen.