welche Skriptsprache für Chat?

hoffe das einige mir einen tipp geben können. und zwar frage ich mich welche skriptsprache für einen chat den server am wenigsten belasten würde, z.b. flash oder java? oder gibts andere alternativen? soll schon moderne funktionen haben...

und nehmen wir mal einen dedizierten server in der 100€/mt-klasse:
mit wievielen chattern würde er max. klarkommen wenn die seite rund 2000 besucher/tag hat?
ich weiss dass andere faktoren auch eine rolle spielen, aber mal so als hausnummer oder erfahrungswerte.

am serverschonensteen ist comet, eine ajax "weiterentwicklung"

z.b. meteorserver.org

er nutzt clientseitig javascript und dürfte ein paar tausend chatter gleichzeitig verkraften.

ich glaub ich hab mich missverständlich ausgedrückt. ich hab nun chatskripte gesucht und zwei davon sind in der endauswahl:
der eine basiert auf flash https://www.tufat.com/s_flash_chat_chatroom.htm und der andere auf ajax https://blueimp.net/ajax/

was schätzt ihr, welcher von beiden belastet den server mehr? und wieviele chatter kann er bei etwa 2000 besucher/tag verkraften?

ich will keine wissenschaftlichen aussagen, nur eure schätzung.
würden z.b. 100 chatter und die 2000 besucher am tag so einen server in die knie zwingen?

2000 besucher am tag sind für einen Server lächerlich. Aber ein chat mit der falschen technik kann ein killer sein. Wenn Du 100 chatter hast und einen php/ajax chat, brauchen die ja alle auf dem Server einen eigenen http-Thread vielleicht noch einen PHP-Prozess. Also haben wir auf dem Server 100/200 Threads gleichzeitig, hier ist dann der RAM das limit. Weiterhin greifen diese 100/200 Threads gleichzeitig auf die mySQL-DB zu. Was entsprechend viel CPU braucht.

Nun meine Schätzung:
Mit feintuning möglich. Je nach Server.

Ab einer gewissen Userzahl muss man sich "wissenschaftliche" Gedanken machen, da das Http nun mal nicht für einen Chat gebaut ist.

meteorserver.org soll locker 10.000 Chatter schaffen.

danke grossy, hab mich bei meteor eingelesen. leider habe ich keine programmierkenntnisse und muss daher auf ein fertiges chatscript setzen.

was meinst du zum flashchat, ist er resourcen-freundlicher als ajax oder ist es das gleiche in grün?

technisch gesehen machen beide das selbe, es wird von daher egal sein.
Du musst halt sehen, dass Dein Apache mindestens soviele Threads straten kann, wie User eingelogt sind. Auch MySql muss mindestens so viele Verbindungen erlauben, wie User eingelogt sind. Für den Server sieht es halt wie 100 gleichzeitige Nutzer aus, die alle 2 Sekunden eine Seite aufrufen. das macht 180.000 PI pro Stunde

socom hat geschrieben:der eine basiert auf flash https://www.tufat.com/s_flash_chat_chatroom.htm und der andere auf ajax https://blueimp.net/ajax/

was schätzt ihr, welcher von beiden belastet den server mehr?

Javascript hat das grundsätzliche Problem, dass es netzwerkseitig nur zustandslose Einbahnstraßen unterstützt. Eine Verbindung kann immer nur vom Browser in Richtung Server aufgebaut werden und wird nach Abholen des gewünschten Objekts (HTML-Seite, Grafik, etc) wieder geschlossen.
Ein Chat benötigt aber sinnigerweise eine Verbindung, die in beide Richtungen verläuft, der Teilnehmer möchte ja nicht nur Text senden, sondern auch die Antwort empfangen, und zwar sobald sie auf dem Server verfügbar ist und nicht erst, wenn er sie abruft.

Das Senden ist bei AJAX (lies: Javascript) natürlich kein Problem, der zeitnahe Empfang wird allerdings so gelöst, dass immer wieder neue Abfragen an den Server gestartet werden müssen.
Flash und Java bringen demgegenüber vollwertige Netzwerkfunktionen mit, können somit Verbindungen wiederverwerten und auf Daten an einer bestehenden Verbindung warten. Der Server kann seine Daten also jederzeit über die bestehende Verbindung schicken, ohne, dass eine explizite Anfrage seitens des Browsers erfolgen müsste.

Hinzu kommt, dass das bei Javascript eingesetzte HTTP einen massiven Protokollüberhang erzeugen dürfte. Zu zweieinhalb Wörtern Nutzdaten dürfte jedesmal, d.h. bei jedem einzelnen gesendeten und empfangenen Text, bis zu mehrere Hundert Bytes an Protokolldaten hinzukommen.
Flash und Java können auf Chatanwendungen ausgelegte, eigene Protokolle verwenden, zu den besagten zweieinhalb Wörtern kämen nur ein, zwei Dutzend Bytes Protokoll, entsprechend effizienter sind sie.

Du kannst das mit einem Telefongespräch vergleichen: Flash und Java ermöglichen normales Sprechen miteinander; bei Javascript müsstest du nicht nur für jeden Satz, den du sagst, neu wählen, sondern auch für (beinahe) jede Antwort, die du erwartest, und obendrein auch noch um die Antwort bitten.

Theoretisch ist Javascript dementsprechend was die Resourcen angeht im deutlichen Nachteil gegenüber Flash und Java.

@Mork vom Ork
Grudsätzlich hast Du Recht, möchte nur noch was hinzufügen:

1.
Comet löst dieses Problem der zustandslosen Einbahnstraße mittels Javascript
https://en.wikipedia.org/wiki/Comet_(programming)

2.
Der hier vorgeschlagene Flash-Chat nutzt serverseitig php. Damit läuft auf dem Server für jeden User ein Prozess mit X Megabyte Hauptspeicher, den entspechenden Context-Switches und eier gewaltigen Menge an SQL-Polls. Also genauso suboptimal. Wenn man einen Flash-Chat sauber einsetzten will, dann mi entsprechender Server-Software, und nicht mit php.

grossy hat geschrieben:1. Comet löst dieses Problem der zustandslosen Einbahnstraße mittels Javascript
https://en.wikipedia.org/wiki/Comet_(programming)

Das ist keine Lösung, das ist der einzig gangbare Weg, die Angelegenheit halbwegs erträglich zu gestalten, denn Busy Polling wäre restlos beknackt.

2. Der hier vorgeschlagene Flash-Chat nutzt serverseitig php.
[…]
Wenn man einen Flash-Chat sauber einsetzten will, dann mi entsprechender Server-Software, und nicht mit php.

Das hat nichts mit Flash zu tun und auch nicht mit PHP, sondern ist ein produktspezifisches Problem.

Mal abgesehen davon, dass ich mich nicht speziell zu den vorgeschlagenen Produkten äußern wollte, sondern allgemein zur Frage nach Javascript, Flash und Java (vielleicht wurde das nicht deutlich genug), sollte hier nicht der Eindruck erweckt werden, eine Flash-Lösung wäre schlecht, weil serverseitig PHP eingesetzt würde. Dieser Eindruck wäre schlichtweg falsch: Das Problem bei diesem einzelnen Produkt ist, dass a) serverseitig ein Webserver eingesetzt wird und b) die Serverkomponente möglicherweise schlecht gelöst wurde. Das kann jedoch mit Javascript und Perl genauso passieren und andersrum kann man genauso mit Flash und PHP ein effizienteres System aufbauen.

Der einzige Vorteil, den ich bei Javascript sehe, ist, dass es sich vielleicht etwas nahtloser in die Webseite einfügt. Diesen Vorteil erkauft man sich mit der ungeeigneten Netzwerkebene.

Serverseitig sollte man sich tunlichst von webserverbasierten Lösungen fernhalten, Webserver sind für solche Anwendungen noch weniger gedacht als Javascript eh schon ist.
Nun war nach der Serverseite nicht gefragt, ich hätte es aber vielleicht erwähnen sollen, anstatt mich auf die Protokollproblematik zu beschränken.

Falls allerdings ein eigener (virtueller / Root-Server) vorhanden ist, würde ich mir ja ein seit Jahrzehnten erprobtes System anschauen: IRC. Das ist ausgereift und es gibt sowohl eigene IRC-Clients als auch Komponenten, die sich in Webseiten einbinden lassen. Aber dies nur am Rande.

ich wusste nichtmal das es einen unterschied zwischen java und javaskript gibt
verstehe ich das so richtig, dass vorhandene chat skriptsprachen eigentlich alle ein fauler kompromiss sind und die alternative dazu irc ist, was ziemlich bescheiden aussieht und verwirrend ist ?
wie machens da die grossen? chat4free.de scheint ja java zu benutzen... haben die für jeden channel einen server oder was?

irgendwie bin ich jetzt verwirrter als vorher
hypothetisch:
eine seite hat 5000 besucher am tag und max. 150 chatter gleichzeitig. und die seite läuft auf so einem server https://www.df.eu/germany/produkte/mana ... er-l2.html
welches chatskript wär geeignet? auf sourceforge ist bei einigen die rede von "...needs less recources" obwohl der chat mit php oder ajax programmiert ist. wenn ich euch richtig verstanden habe sind die dinger ja doch resourcenfresser.
beim flashchat hab ich was interessantes in der changelog https://www.tufat.com/changeLog2.htm entdeckt und würd gerne eure meinung dazu wissen:

In 4.8.0, we have added a significant new feature: chat caching. With caching, your server load will be substantially reduced. And with the new "full caching" option, you can use FlashChat in the default installation (not integrated with a CMS or bulletin board) without any database at all! At the second step of installation, you will be prompted to determine whether to use FlashChat in the default mode, or with "partial caching" or "full caching". Here's what they mean:
Partial caching: database access is only made "on demand". You can use all of the normal FlashChat features, but a connection to the database is only created when needed. Features like CMS integration, bots, user profiles, socket server, and all other features of FlashChat are still usable in this mode.
Full caching: No database is used at all. In other words, the chat messages, room list, and user list are all stored in plain text files. Although this increases the number of file read/writes dramatically, and in some cases can slow down the chat, the overall server load is significantly reduced since a good chunk of server resources goes into database connections and accesses.

was passiert da genau und macht es wirklich sinn im bezug auf die entlastung des servers?

socom hat geschrieben:ich wusste nichtmal das es einen unterschied zwischen java und javaskript gibt :o

Javascript und Java haben nichts miteinander zu tun, außer, dass es Programmiersprachen sind und Javascript-Erfinder Netscape seinerzeit auf den Java-Zug aufspringen wollte. Ursprünglich hieß Javascript Livescript, der Sprachstandard nennt sich ECMAScript.

verstehe ich das so richtig, dass vorhandene chat-skriptsprachen eigentlich alle ein fauler kompromiss sind

Nein und ja. Um das nochmal aufzudröseln: Ein Chat hat drei Komponenten, die Benutzerschnittstelle, den Übertragungsweg, den Server. Die Last entsteht auf dem Übertragungsweg und in der Serversoftware, darauf musst du achten, nicht auf die „Chat-Skriptsprache“.

1. Die Sprache, in der die Benutzerschnittstelle realisiert wurde, kann nur einen Anhaltspunkt geben. Javascript kann nichts anderes als HTTP, Flash hingegen kann auch andere, für einen Chat effizientere Übertragungsprotokolle einsetzen - dieser Vorteil muss dann aber auch genutzt werden. Ein Flash-Chat auf Browserseite hat keinen Vorteil, wenn er wie sein Javascript-Kollege auf HTTP setzt, dann ist das Jacke wie Hose.
Deshalb kann man nicht pauschal sagen, diese oder jene Skriptsprache wäre im Vorteil. Es kommt auf die Umsetzung an.

2. Wenn du dich um die Serverlast sorgst, musst du logischerweise gucken, was serverseitig passiert. Auch hier gilt wieder: Es ist vollkommen wurscht, ob im Browser Flash oder Javascript läuft, wenn auf dem Server das gleiche Verarbeitungsprinzip eingesetzt wird. Und ebenso: Es ist wurscht, welche Sprache auf dem Server eingesetzt wird, wichtig ist die Umsetzung.
Deshalb kann man auch nicht pauschal sagen, diese oder jene Sprache wäre serverseitig von Vorteil. Es kommt auf die Umsetzung an.

Kurzum: Schau nicht auf die Sprachen, schau, wie die Technik funktioniert.

Die beiden Systeme, die du rausgesucht hast, funktionieren augenscheinlich nach dem gleichen, denkbar schlechtesten Prinzip, HTTP-Übertragung und ein ordinärer Webserver mit angehängter Datenbank zur Verarbeitung.
Das System, das grossy vorgeschlagen hat, ist schon deutlich eleganter, denn es setzt auf einen spezialisierten Server. Ich habe als Kontrast dann noch IRC eingebracht, da hast du alle wichtigen Komponenten quasi in Idealform, einen spezialisierten Server und ein spezialisiertes Übertragungsprotokoll.

und die alternative dazu irc ist, was ziemlich bescheiden aussieht und verwirrend ist?

Dass IRC bescheiden aussieht und verwirrend ist, kann ich jetzt nicht nachvollziehen, das hängt schließlich von der Benutzerschnittstelle ab. Du setzt deine Besucher schließlich auch nicht dem HTTP-Protokoll aus, nicht einmal HTML, obwohl du es benutzt.

wie machens da die grossen? chat4free.de scheint ja java zu benutzen...

Wenn sie Java (nicht Javascript) nutzen, dann fallen sie vermutlich unter die dritte Variante, spezialisiertes Protokoll und spezialisierter Server. Nutzen sie Javascript, wird das wegen der Beschränkung von Javascript auf HTTP die Variante 2 sein, spezialisierter Server.

auf sourceforge ist bei einigen die rede von "...needs less recources" obwohl der chat mit php oder ajax programmiert ist.

Less bedeutet weniger, nicht wenig. Jemand mit 180 kg wiegt auch weniger als jemand mit 200 kg - wenig wiegen beide trotzdem nicht. Und nochmal: Komm' von den Sprachen weg, das sind keine direkten Leistungsindikatoren (wobei Ajax auch keine Sprache ist).

Partial caching: / Full caching:

was passiert da genau und macht es wirklich sinn im bezug auf die entlastung des servers?

Was beim Partial Caching passiert, ist aus dem Text nicht wirklich zu entnehmen, beim Full Caching wird wohl statt in eine Datenbank in eine Textdatei geschrieben. Das hat den Vorteil, dass die Datenbank keine Leistung mehr fressen kann. Das hat aber auch den Nachteil, dass keine Datenbank mehr da ist, die verhindert, dass sich die ganzen Benutzer bzw. die von ihnen verursachten Datenströme auf dem Server gegenseitig in die Quere kommen. Diese Kollisionsvermeidung muss dann anderweitig geregelt werden, vermutlich findet sich dort deshalb der Hinweis, dass zwar der Server durch Full Caching entlastet, aber gleichzeitig der Chat langsamer werden kann.

Um auf deine ursprüngliche Frage zurückzukommen: Welches der beiden von dir vorgeschlagenen Systeme wieviele Benutzer auf deinem Server bedienen kann, musst du selbst herausfinden, das wird dir keiner sagen können.
Ich hätte vermutlich gar nicht erst mit den technischen Hintergründen anfangen sollen …

Ich hätte vermutlich gar nicht erst mit den technischen Hintergründen anfangen sollen …

ne, ist echt informativ was du geschrieben hast. das habe ich so nicht gewusst. bin nun um einiges schlauer was das betrifft, danke euch.

ich werd einfach mal ein paar passende skripte testen und die serverlast irgendwie messen.