@__deets__: da hast Du recht. Mein nginx-Server hat gerade 200 Websocketverbindungen offen, die dann zu 200 Verbindungen zum Django-Server führen, alles ohne Probleme.
@Zoja: dagegen jeweils eine neue Verbindung mit TLS-Handshake dauert ziemlich lange. Daher auch mein Hinweis, eine Single-Page-Anwendung zu schreiben, so dass man die Websocketverbindung nur einmal aufbauen muß, nur eine Technologie nutzt.
Da Du das über Heroku deployst, ist sowieso vorgesehen, dass Du viele Worker benutzt, die unabhängig arbeiten.
Wie viele Nutzer erwartest Du denn parallel für Deinen Chat?
@DasIch: die Verbindungen von Websockets werden genauso über einen Load-Balancer verteilt. Bei 1000 Verbindungen pro Worker ist es statistisch gesehen sehr unwahrscheinlich, dass plötzlich nur die Verbindungen zu einem Worker hohen Load verursachen. Im Notfall kann man ja auch Websockets schließen, die dann vom Client automatisch neu aufgebaut werden.
Flask Socket.io Chat | Einige Fragen
Ersteres gilt ja auch fuer ein Websocket-Szenario, letzteres ist ein generelles Problem - Laptop zu, Laptop auf, ICE-Internet hin, weg und wieder hin. Das muss ja auch eh geloest werden.DasIch hat geschrieben: Der Vorteil ist dass du die Verbindungen wesentlich leichter über einen Load Balancer auf mehrere Server verteilen kannst. Deployments werden einfacher weil du dir keine Gedanken darüber machen musst dass Verbindungen verloren werden usw.
Damit kein Missverstaendnis entsteht: ich mache kein Web mehr, mich interessiert das wirklich weil ich es nicht mehr besser weiss
Was ich aber mache ist low-level-Linux-Kram, und die Menge an Interrupts und Systemaufrufen fuer Verbindungsaufbauten haben auch kosten.Ich glaube es wird sehr sehr lange dauern, bis ich 1000 gleichzeitige User erreiche. Aber die User sind lange auf der Webseite. Es ist eine Patreon ähnliche community.Sirius3 hat geschrieben:@__deets__: da hast Du recht. Mein nginx-Server hat gerade 200 Websocketverbindungen offen, die dann zu 200 Verbindungen zum Django-Server führen, alles ohne Probleme.
@Zoja: dagegen jeweils eine neue Verbindung mit TLS-Handshake dauert ziemlich lange. Daher auch mein Hinweis, eine Single-Page-Anwendung zu schreiben, so dass man die Websocketverbindung nur einmal aufbauen muß, nur eine Technologie nutzt.
Da Du das über Heroku deployst, ist sowieso vorgesehen, dass Du viele Worker benutzt, die unabhängig arbeiten.
Wie viele Nutzer erwartest Du denn parallel für Deinen Chat?
@DasIch: die Verbindungen von Websockets werden genauso über einen Load-Balancer verteilt. Bei 1000 Verbindungen pro Worker ist es statistisch gesehen sehr unwahrscheinlich, dass plötzlich nur die Verbindungen zu einem Worker hohen Load verursachen. Im Notfall kann man ja auch Websockets schließen, die dann vom Client automatisch neu aufgebaut werden.
Single Page macht hier Sinn (verstehe ich das richtig):
Es gibt Seite A und Seite B, User hat Seite A auf und im neuen Tab seite B, weil es keine Single Page Anwendung ist, werden 2 Sockets aufgemacht für den selben User? Bei Single Page ist es egal, ob die Seiten im neuen Tab auf sind, denn es ist die selbe Seite immer, nur der content wird ausgetauscht.
Frage: Gäbe es hier für SEO Probleme? Man will ja mit möglichst vielen Unterseiten vertreten sein. Macht man bei Single Page auch den jeweiligen content über unterschiedliche URL's erreichbar, nur wird dieser anders geladen?
---
Das mit dem TLS-Handshake höre ist zum ersten mal. Wird dieser gemacht/benötigt bei AJAX requests?
Natuerlich wird ein TLS handshake gemacht - bei allen HTTPS-Verbindungen, und ohne die exakt gleiche Verbindung zu nutzen sollte eigentlich die Javascript same origin policy den Riegel vorschieben. Aber das ist nichts was *du* machen musst, das tut dein Browser schon fuer dich. Es geht nur darum, dass es einiges an overhead gegenueber einer stehenden Verbindung gibt.
Achso, d.h. alle 10 sekunden für jeden user so eine AJAX pull zu machen, würde dazu führen, dass unnötige handshakes gemacht werden. D.h. also es wäre doch besser die Sockets zu nutzen und alle user auf jeder page zu connecten, verstehe ich das richtig?__deets__ hat geschrieben:Natuerlich wird ein TLS handshake gemacht - bei allen HTTPS-Verbindungen, und ohne die exakt gleiche Verbindung zu nutzen sollte eigentlich die Javascript same origin policy den Riegel vorschieben. Aber das ist nichts was *du* machen musst, das tut dein Browser schon fuer dich. Es geht nur darum, dass es einiges an overhead gegenueber einer stehenden Verbindung gibt.
Alle 10 Sekunden ist viel zu langsam. Wenn ich mit dir chatte, dann schreibe ich dir Nachrichten im Sekundentakt. Und so etwas wie zB "tippt gerade"-Markierungen sind ja instantan.
Websockets sind fuer sowas gedacht, und wenn du mal wirklich so weit bist, dass das nicht mehr skaliert, dann hast du so viele User, dass du dir leisten koennen solltest, entsprechend dickerere Hardware zu kommisionieren oder die Investitionen in zB load-balancer und andere Skalierungstechniken sich rechnen.
Websockets sind fuer sowas gedacht, und wenn du mal wirklich so weit bist, dass das nicht mehr skaliert, dann hast du so viele User, dass du dir leisten koennen solltest, entsprechend dickerere Hardware zu kommisionieren oder die Investitionen in zB load-balancer und andere Skalierungstechniken sich rechnen.
Ja das sehe auch so.__deets__ hat geschrieben:Alle 10 Sekunden ist viel zu langsam. Wenn ich mit dir chatte, dann schreibe ich dir Nachrichten im Sekundentakt. Und so etwas wie zB "tippt gerade"-Markierungen sind ja instantan.
Websockets sind fuer sowas gedacht, und wenn du mal wirklich so weit bist, dass das nicht mehr skaliert, dann hast du so viele User, dass du dir leisten koennen solltest, entsprechend dickerere Hardware zu kommisionieren oder die Investitionen in zB load-balancer und andere Skalierungstechniken sich rechnen.
Du hast mich trotzdem etwas falsch verstanden. Einen voll funktionierenden Chat, der mit Websockets arbeitet habe ich bereits, dieser ist aber nur auf einer Unterseite eingebunden, d.h. wenn user A auf der chat seite ist, kann er auch instant mit allen anderen usern chatten. Nur wenn user A jetzt nicht auf der Chat seite ist, dann ist er nicht connected, sollte aber trotzdem mitkriegen, ob neue Nachtrichten da sind, hierfür war das alle 10 sekunden updaten gedacht (auf allen Seiten außer chat seite). user A würde dann irgendwo angezeigt bekommen, dass es ungelesene chatnachrichten gibt und könnte wieder auf die Chat seite gehen, wo er wieder connecten würde.