Thread: PHP-Chat; DB oder txt? Traffic?

Ich will einen kleinen Chat für ne comunity seite coden
einfach nur für eingeloggte user (system ist schon da) ne möglichkeit, sich in nem chat zu unterhalten (ganz klassisch nur text, smilies, und links; ohne viel schnickschnack...also nur ein raum usw...)
was ist vom speed her besser? ne text-datei, oder mysql-db-einträge?
dann will ich das ganze mit ajax machen. hat da jmd tricks wie man trotz guter reload-zeit (also fast sofortiger anzeige des textes) geringen traffic hat?
ich würde die letzte id die empfangen wurde speichern und dann jeweils hinzufügen lassen was nach der id kam (wird also meistens 0 byte sein)

bin für alle vorschläge offen

Hi.

• Reine Text-Datei ist sicherlich am besten, weil's am wenigsten Overhead hat.
• Traffic ist mit Ajax sicher kein Problem.
• Viel wahrscheinlicher wird es ein Problem der Serverlast, weil pro Anfrage (und jede Aktualisierung ist ja ne Anfrage) ein eigener PHP-Prozess erzeugt werden muss, der einige 10 MB an Speicher benötigt. Wenn da mehrere Clients im Sekundentakt den Server bombarieren, ist das nicht all zu gut. Ich würde dir also raten, mit einer höheren Aktualisierungszeit (zB 14 oder 20 Sekunden) zu beginnen, und abzuwarten, ob es überhaupt wen stört.
  Schließlich ist diese Zeit ja nur die maximale Zeit, die man warten muss. Im Durchschnitt ist die Wartezeit ja die Hälfte (also 7 oder 10 Sekunden). Das ist dann eh sehr ok.
• Du kannst es ja so machen, dass der eigene Eintrag immer sofort beim Sender selbst erscheint. Dann fällt es nicht so auf, dass die anderen die Nachricht erst einige Sekunden später empfangen

LG, bmk.

Es wird schwierig, den Traffic bei einem HTTP-basierten Chat mit kurzer Latenzzeit gering zu halten. Dazu fehlt dem HTTP-Protokoll einfach die Persistenz und damit die Möglichkeit, das Observer-Modell zu verwenden.

Alles, was du tun kannst, ist wohl eine saubere Abstimmung zwischen Verzögerung und Frequenz der Anfragen zu finden. Jeder deiner AJAX-Request bringt ja neuen Traffic mit sich wegen der HTTP-Header, auch wenn kein Content gesendet wird.

Edit

Mmhh vertrau lieber mal der Aussage von bmk als meiner   

@bmk: ok also textdateien...wird kein prob
traffic mit ajax=kein problem? was hat das mit ajax zu tun? der fordert doch trotzdem ne neue seite an
hm...da das ganze zu teambesprechungen genommen werden soll, wären 14-20s zuviel
warum die maximale zeit? wenn ich 14s einstelle dann lädt er nach 14sec neu...und nie eher. oder hab ich dich falsch verstanden?
bei senden würde ich es so machen, dass es ebenfals ein ajax-request wird, der gleichzeitig die anderen daten empfängt.

welche alternative gibt es noch zu nem http/php chat?

Trotz HTTP-Server sind es ja immer noch nur reine Text-Daten, die gesendet werden. Über ein paar Bytes pro Anfrage wirst da nicht kommen.


Bei so etwas musst du aufpassen - es ist doof, wenn beim einen Chatteilnehmer die Reihenfolge der Nachrichten anders ist, als beim anderen Teilnehmer. Da kann ein Gespräch leicht zerrissen werden, weil Antworten nicht mehr richtig eingeordnet werden können.


Das wär aber auch nur, wenn man PHP als CGI installiert und der Webserver so für jede Anfrage einen eigenen Prozess öffnen muss. Auch wenn ich auf dem Gebiet nicht so fit bin, wäre es sicher sinnvoller, PHP in apache als Modul einzubinden, dann läuft alles im Apache-Prozess ab - was vor allem bei vielen Anfragen ein großer Performance-Gewinn sein sollte.

Viele Grüße,
Benno

Kommt drauf an, was du überträgst. Wenn du immer nur jenen Teil überträgst, der für den anfragenden Client neu ist, und es ist seit dem letzten Request nichts neu, dann wird auch einfach nichts zurückgeschickt. Oder nur ein kurzer "nix neues"-Statuscode.
Wäre ganz leicht: Du brauchst nur beim Request einen Timestamp mitschicken, wann der Client das letzte mal aktualisiert hat, und nur jene Messages zurückliefern, die seither dazugekommen sind. Minimaler Traffic.


Die 14 Sekunden gelten nur dann (maximal), wenn jemand genau in jener Millisekunde etwas tippt, nachdem dein Client den aktuellen Stand abgefragt hat. Nur dann musst du die vollen 14 Sekunden auf die Antwort deines Freundes warten.
Im Minimalfall hingegen aktualisiert sich dein Client genau ein paar Millisekunden nachdem dein Freund geschickt hat. In diesem Fall hättest du also seine Nachricht mit nur wenigen Millisekunden Verzögerung bei dir.
Die Frage ist also nicht nur, wann dein Client aktualisiert, sondern wie kurz oder lange die inzwischen eingetroffenen neuen Nachrichten her sind.
Im Durchschnitt wird sich also eine Verzögerung der halben Aktualisierungszeit ergeben. War das nun verständlicher...?

Dadurch ergibt sich aber auch, dass du selbst bei 16 Sekunden eine Verzögerung von durchschnittlich etwa 5 Sekunden erhältst. Rechnet man noch dazu, dass dein Kollege ja fürs Tippen der Nachrichten auch eine gewisse Zeit braucht, sind 8 Sekunden ziemlich gut. ;-)

ok gut
jetzt noch letztens: gibt es alternativen? mit kommt es auf ne schnelle ladezeit an
der chat soll so gut wie keine funktionen haben, aber möglichst selbst anpassbar sein

Aber bitte den Timestamp nicht per Javascript auslesen. Du kannst nie davon ausgehen, dass der User die Uhr richtig gestellt hat und wenn die nicht mit dem Server synchronisiert ist: Gute Nacht   

Sinnvoller wär es da, wenn der Server speichert, wann die letzte Anfrage kam und dementsprechend Nachrichten zurückschickt. Sollte mit Sessions kein großes Problem sein.

Wenns wegen der Schnelligkeit der Zeit ist: Du kannst ja die Zeit mal höher haben und dann langsam niedriger stellen und die Last am Server beobachten.

Viele Grüße,
Benno

Der Server könnte ja auch einfach "seinen" Timestamp mitschicken ;-)

Aber was muss der Timestamp überhaupt am Client tun? Es reicht doch, wenn der Server weiß, wann die letzte Anfrage kam um zu wissen, welche Nachrichten er zurückschicken muss.
Der client braucht nur zu wissen, dass er alle X Sekunden eine Anfrage zu stellen hat.