Chat in HTML mit einer Scriptsprache ohne Reload

[Sandra]

Hallo,
Ich war gerade auf einem Chat http://www.lechat.de/.
Der geht ohne Reload aber wie?
Da steht was von 'HTML-Stream'!
Was ist das und wie geht das?
Viele Grüße
Sandra

[Cheatah]

Hi,

Da steht was von 'HTML-Stream'!
Was ist das

eine Vergewaltigung des Protokolls HTTP, welches zustands- und verbindungslos ist und somit für einen Chat noch ungeeigneter als z.B. FTP.

und wie geht das?

Es ist besser, manche Fragen nicht zu beantworten. Ein auf HTTP (was durch HTML impliziert wird) basierender Chat stellt eine Beschädigung des Internets dar.

Cheatah

[Stefan Muenz]

Hallo Cheatah,

Es ist besser, manche Fragen nicht zu beantworten. Ein auf HTTP (was durch HTML impliziert wird) basierender Chat stellt eine Beschädigung des Internets dar.

Darf ich jetzt aber mal ganz dumm fragen, warum eigentlich? Denn wer bitte schreibt vor, wie viele Kommunikationsaktionen zwischen einem HTTP-Client und einem HTTP-Server pro Minute oder so vorgeschrieben sind? Und wer schreibt vor, dass immer nur komplette HTML-Seiten uebertragen werden muessen, und nicht mal nur einzelne HTML-Strings? Koennte es nicht sein, dass die Zustandslosigkeit des HTTP-Protokolls kein Grund ist, dass Client und Server trotzdem ihr eigenes Pingpong darueber spielen? Also ich kann ja verstehen, wenn jemand rumtobt, wenn <blockquote> fuer Texteinrueckungen missbraucht wird - aber warum jemand tobt, wenn ueber ein zustandsloses Protokoll doch noch eine Art Quasi-Verbindung (z.B. ueber intervallische Aufrufe) realisiert wird, kann ich daran keine Vergewaltigung erkennen. Die Frage ist halt, ob der Server die vielen Anfragen verkraftet. Aber wenn - warum nicht?

viele Gruesse
  Stefan Muenz

[Cheatah]

Hi,

Darf ich jetzt aber mal ganz dumm fragen, warum eigentlich? Denn wer bitte schreibt vor, wie viele Kommunikationsaktionen zwischen einem HTTP-Client und einem HTTP-Server pro Minute oder so vorgeschrieben sind?

die Menge _eigenständiger_ Requests darf man sich gerne frei wählen; das einzige Problem dabei ist der gigantische Overhead. Für einen Chat ist hierbei das Problem, dass es serverseitig, ähm, _schwer_ fallen wird, zwischen den einzelnen Requests irgendeine Verbindung zu knüpfen; und dass vom Client aus Requests "ins Blaue" geschossen werden müssen, bevor er erfahren kann, ob sich etwas geändert hat.

Und wer schreibt vor, dass immer nur komplette HTML-Seiten uebertragen werden muessen, und nicht mal nur einzelne HTML-Strings?

Höchstens der Browser, welcher immer ein komplettes Dokument pro Request erwartet. Bei anderen Clients kann man sich das gestalten wie man will.

Koennte es nicht sein, dass die Zustandslosigkeit des HTTP-Protokolls kein Grund ist, dass Client und Server trotzdem ihr eigenes Pingpong darueber spielen?

Die Zustandslosigkeit erschwert das ganze nur. Das wirkliche Problem ist jedoch die _Verbindungs_losigkeit - HTTP ist so designed, dass nach Absetzen des Responses (was in Folge dieses Designs in aller Regel als "in einem Stück" erwartet werden kann; Stichwort Timeout-Fehlerkennung) die Verbindung gekappt wird, noch bevor der Client überhaupt alle (evtl. sogar irgendwelche) Daten erhalten hat. Insbesondere ist es _nicht_ Sinn von HTTP, über eine einzige Verbindung mehrere Requests mit mehreren Responses zu tätigen. Request, Response, Schluss. Der nächste Request hat mit dem vorherigen nichts mehr zu tun - was die Begriffe "nächster" und "vorheriger" nebenbei bemerkt ad absurdum führt.

Um mal einen (schlechten) Vergleich mit dem wahren Leben [tm] zu ziehen: Stell Dir zwei Menschen auf einem großen, belebten Platz vor (dem Netz). Einer davon (der Client) hat einen Tennisball in der Hand, einer einen Tennisschläger (der Server). Wenn nun der Client seinen Ball zum Server wirft, schlägt dieser ihn zurück - hoffentlich an den anderen Leuten vorbei. Das ist HTTP.

Will man nun einen Chat bauen, kann man entweder hin und her werfen, mit den oben genannten Problemen; oder man versucht eine Verbindung offenzuhalten. Dazu würde der Server den Ball nehmen, eine Nadel mit einem langen Faden durchstechen, die Nadel in eine Armbrust legen und damit zurück zum Client ballern. Anschließend hämmern die beiden ständig den Ball zwischen sich hin und her, oder sie fädeln neue Bälle ein usw. Das Problem hierbei ist, dass die Leute auf dem belebten Platz nicht mehr ungehindert passieren können - ein Faden ist im Weg.

Die Frage ist halt, ob der Server die vielen Anfragen verkraftet. Aber wenn - warum nicht?

Weil es erstens nicht um viele Anfragen geht, sondern um eine ganz, ganz lange, die zudem unkonformerweise mehrmals hin und her geht, und weil zwischen Client und Server noch viel mehr Systeme hängen, die das ebenfalls verkraften müssen - vom Proxy über die Firewall bis zum Router.

Mehrere Requests sind zunächst einmal einfach nur 'ne blöde Idee, weil man sich damit viel Arbeit, Traffic[1], Last und Ressourcenverschwendung mit wenig Nutzen aufhalst. Eine offenbleibende Verbindung ist eine Vergewaltigung des Protokolls.

Cheatah

[1] Mindestens dies ist dann wieder etwas, worunter auch andere leiden.

[Stefan Muenz]

Hallo Cheatah,

Für einen Chat ist hierbei das Problem, dass es serverseitig, ähm, _schwer_ fallen wird, zwischen den einzelnen Requests irgendeine Verbindung zu knüpfen;

In der serverseitigen Programmiersprache, die man fuer so einen Chat verwendet, kann man sich ja mit Sessions und dergleichen behelfen. Selbst wenn der Server laengst vergessen hat, mit wem er es zu tun hat - so kann ein Script es immer noch wissen, weil es noch eine offene Session hat.

Höchstens der Browser, welcher immer ein komplettes Dokument pro Request erwartet.

Wie das nun genau funktioniert mit dem Streaming HTML, weiss ich auch nicht. Aber nachdem Dinge wie das DOM sowohl serverseitig als auch clientseitig funktionieren, reicht ja z.B. eigentlich eine DOM-Schnittstelle zwischen server- und client-seitigen Scriptsprachen.

Das wirkliche Problem ist jedoch die _Verbindungs_losigkeit - HTTP ist so designed, dass nach Absetzen des Responses (was in Folge dieses Designs in aller Regel als "in einem Stück" erwartet werden kann; Stichwort Timeout-Fehlerkennung) die Verbindung gekappt wird, noch bevor der Client überhaupt alle (evtl. sogar irgendwelche) Daten erhalten hat.

Hm - also bei meinem lokalen Apache ist "KeepAlive" auf "On" gestellt, und nachdem ich da nie dran gedreht habe, ist das wohl auch die Default-Einstellung. Kommentar im Apache-Konfig-File:

KeepAlive: Whether or not to allow persistent connections (more than

one request per connection). Set to "Off" to deactivate.

Schliesslich habe ich noch da stehen: "KeepAliveTimeout 15". D.h. der Apache haelt die Verbindung mindestens 15 Sekunden bis zum naechsten Request aufrecht. Es gibt auch noch einige weitere Einstellungen zu dem Thema im Apache - jedenfalls ist da einiges einstellbar und nicht unbedingt "Gesetz".

Wenn nun der Client seinen Ball zum Server wirft, schlägt dieser ihn zurück - hoffentlich an den anderen Leuten vorbei. Das ist HTTP.

Auweia, ich hab gar nicht gewusst, dass es im Web so gefaehrlich ist! ;-)

Will man nun einen Chat bauen, kann man entweder hin und her werfen, mit den oben genannten Problemen; oder man versucht eine Verbindung offenzuhalten. Dazu würde der Server den Ball nehmen, eine Nadel mit einem langen Faden durchstechen, die Nadel in eine Armbrust legen und damit zurück zum Client ballern. Anschließend hämmern die beiden ständig den Ball zwischen sich hin und her, oder sie fädeln neue Bälle ein usw. Das Problem hierbei ist, dass die Leute auf dem belebten Platz nicht mehr ungehindert passieren können - ein Faden ist im Weg.

Danke fuer diesen wunderbaren Vergleich! Endlich mal was, worunter man sich was vorstellen kann ;-)
Allerdings: Clients und Server gibts immer im Internet. Was tun den ein IRC-Client und ein IRC-Server so viel anderes? Ping Pong, die ganze Zeit. Oder gibt es da ein Geheimnis bei IRC, das ich nicht kenne?

... und weil zwischen Client und Server noch viel mehr Systeme hängen, die das ebenfalls verkraften müssen - vom Proxy über die Firewall bis zum Router.

Das ist natuerlich richtig. Aber auch wenn ich hier hocke und auf irc.kickchat.com ein Schwaetzchen halte, ist das Routing nicht kuerzer. Allenfalls der Datenaustausch zwischen Server und Client ist fuer den Zweck optimiert. Aber der Unterschied ist allenfalls relativ.

viele Gruesse
  Stefan Muenz

[Michael Schröpl]

Hi Stefan Muenz,

Hm - also bei meinem lokalen Apache ist "KeepAlive" auf "On" gestellt, und nachdem ich da nie dran gedreht habe, ist das wohl auch die Default-Einstellung. Kommentar im Apache-Konfig-File:

KeepAlive: Whether or not to allow persistent connections (more than

one request per connection). Set to "Off" to deactivate.

welcher Browser ist so konfiguriert, daß er das unterstützt?
(Selbst bei Mozilla gilt das Feature als "experimentell - bei Problemen bitte abschalten". Lies mal Preferences / Advanced / Networking.)

Welcher Proxy unterstützt das?

Welche Firewall unterstützt das?
Wahrscheinlich keine - denn man könnte eine DOS-Attacke auf sie fahren, wenn man ganz viele persistente Verbindungen aufmacht.
Dasselbe gilt natürlich auch für den Apache-Server ... deshalb gibt es ja diese vielen Schräubchen, mit denen man das KeepAlive feintunen sollte.

Wir haben mit KeepAlive diverse Experimente gemacht - spätestens an der Firewall war es vorbei mit der Herrlichkeit. Das Konzept ist schön - aber in der Realität nützt es derzeit noch wenig.

KeepAlive ist eine dem HTTP nachträglich aufgepfropfte Idee, welche aus der Erkenntnis geboren zu sein scheint, daß eine "real existierende" HTML-Seite üblicherweise weitere HTTP-Ressourcen referenzieren wird (Bilder, JavaScript-Seiten, CSS-Definitionen etc.). Eine Analyse der Paket-Verteilung eines durchschnittlichen Webservers wird mit hoher Wahrscheinlichkeit zu dem Ergebnis kommen, daß der Client Verbindungen in "Sprays" aufbaut - "eine Handvoll" pro Mausklick.

Genau darauf sind die Apache-Einstellungen (Anzahl Requests bzw. Timeout-Zeit) ausgelegt: Die Verbindung soll lange genug leben, damit alles, was aus Sicht des Anwenders (der ja HTTP nicht versteht) seine "Seite" komplett übertragen werden kann - eben das HTML-Dokument plus die darin referenzierten Dateien. Während dieser Phase sollen möglichst nicht mehrere TCP/IP-Verbindungen aufgebaut werden müssen.
Insofern kann (und sollte) man diese Werte dem "Charakter" der eigenen HTML-Seiten entsprechend einstellen, wenn man über die entsprechenden Informationen verfügt. (Was natürlich schwierig ist, weil die Anzahl der Dateien pro Seite zweifellos von Dokument zu Dokument streut.)

KeepAlive ist _kein_ Konzept für _stehende_ Verbindungen via HTTP. Und ob es innerhalb von HTTP überhaupt das leistet, was es leisten will, ist wegen der vielen TCP/IP-Knoten zwischendrin, die alle mitspielen müßten, sehr die Frage.

Dasselbe Ziel ließe sich mit einer Erweiterung von HTTP erreichen, wenn ein HTTP-Request eine _Liste_ von URLs anfordern könnte (alle mit demselben Satz von HTTP-Headern und ggf. derselben HTTP-Methode - mehr als ein "PUT" auf einmal wird nicht gut möglich sein), welche dann
1. vom Server berechnet und gesammelt,
2. in einer wie auch immer gearteten Archiv-Struktur verpackt und
2. als gemeinsame Archiv-Ressource (natürlich komprimiert) über das Netz übertragen würden.
Dann hätten wir nur einen Request, eine Response, eine TCP/IP-Verbindung und weniger Overhead bei der Adressierung. Der Browser muß das Archiv dann nur noch auspacken - das wäre nicht viel anders, als das Auspacken von *.jar-Dateien, was er ja bereits versteht, denke ich.

Ein solches Protokoll würde den heutigen Gegebenheiten des WWW wahrscheinlich viel besser entsprechen als HTTP/1.1 ... aber schon HTTP/1.1 wird ja von den existierenden Programmen nicht annähernd vollständig umgesetzt (der M$IE ist da ein besonders häßliches Beispiel), wie soll man da ein Nachfolgeprotokoll nicht nur definieren, sondern vor allem etablieren?
(Hm - da müßten sich mal die Apache- und die Mozilla-Entwickler an einen Tisch setzen ... grübel ...)

Allerdings: Clients und Server gibts immer im Internet. Was tun den ein IRC-Client und ein IRC-Server so viel anderes? Ping Pong, die ganze Zeit. Oder gibt es da ein Geheimnis bei IRC, das ich nicht kenne?

Wenn Du eine stehende Verbindung hast, dann kann der Server senden, wann immer er das für sinnvoll hält - und auch _nur_ dann. Wenn nicht, dann kann nur der Client aktiv nachsehen. Und das immer wieder - egal, ob eine neue Nachricht da ist oder nicht.

Und vermutlich sind bei IRC auch die Bälle kleiner.

Viele Grüße
      Michael

[Andres Freund]

Hi,

Ich mische mich jetzt mal ganz frech ein;-), gestattet?

Koennte es nicht sein, dass die Zustandslosigkeit des HTTP-Protokolls kein Grund ist, dass Client und Server trotzdem ihr eigenes Pingpong darueber spielen?  [zuviel weggekürzt] Die Frage ist halt, ob der Server die vielen Anfragen verkraftet. Aber wenn - warum nicht?

1. Halten meines Wissens viele dieser HTML-Chats einfach eine einzige Verbindung zu jedem User offen, und geben immer wieder etwas aus, so dass die Verbindung nie beendet wird, was nun eben dem Sinn von http widerspricht.
2. Ist das so anstrengend für den Server, dass viele dieser HTM-Chats ab 4-5 Besuchern schon in die Knie gehen, und unglaublich viel Traffic verbrauchen.
3. Warum überhaupt benutzen, wenn es etwas viel effektiveres (IRC)gibt, was Traffic und Resourcen spart

mfg Andres Freund

[Stefan Muenz]

Hallo Andreas,

1. Halten meines Wissens viele dieser HTML-Chats einfach eine einzige Verbindung zu jedem User offen, und geben immer wieder etwas aus, so dass die Verbindung nie beendet wird, was nun eben dem Sinn von http widerspricht.

Eigentlich reicht es aber doch, dass sie entweder die neu angefallenden Chat-Daten uebertragen, oder, wenn nichts vorliegt, einen 204-Header. HTTP-Kopfdaten natuerlich in jedem Fall.

Es mag sein, dass HTTP primaer anderen Zwecken dient und nicht gerade fuer diese Art der Client-Server-Kommunikation optimiert ist. Aber nicht von ungefaehr gibt es in Apache&Co. entsprechende Keepalive-Einstellungen. Es steht jedenfalls nirgendwo geschrieben, dass man maximal alle drei Minuten was von einem Webserver wollen darf ;-)

2. Ist das so anstrengend für den Server, dass viele dieser HTM-Chats ab 4-5 Besuchern schon in die Knie gehen, und unglaublich viel Traffic verbrauchen.

Wir haben hier ja einige unter uns (ich weiss nur nicht, ob jemand davon in diesem Thread mitliest), die auf http://www.kingchess.de/ ein SELF-Schachturnier ausgetragen haben. So weit ich weiss, wurde dabei auch fleissig im Chat von Kingchess gequatscht waehrend der Partien. Und von diesem Chat weiss ich, dass er einer dieser "boesen" Web-Chats ist. So weit ich aber auch weiss, verkehren dort deutlich mehr als 4-5 Leute, und dem Server scheints gut zu gehen. Klar, wenn 100 Leute chatten und jeder einen Apache-Prozess von 10MB im Speicher haelt, sind das 1BG, die der Apache RAM braucht fuer den Spass. Keine Frage.

3. Warum überhaupt benutzen, wenn es etwas viel effektiveres (IRC)gibt, was Traffic und Resourcen spart

Weil ein Chat, der vom Layout her und im Browser ablaeuft, eben eher als zu einem Webangebot zugehoerig empfunden wird. Dieses Forum hier ist ja auch web-basiert. Der Grund ist, weil es zu einem Webangebot gehoert. Und wir leisten uns den Luxus, obwohl es den Server belastet, und obwohl wir ebensogut eine Mailingliste oder eine Newsgroup unterhalten koennten.

viele Gruesse
  Stefan Muenz

[Andres Freund]

Hi Stefan

Hallo Andreas,

Arg. Ich heiße Andres ;-)

Erstmal muss man sagen, dass ich dieses Posting etwa um 18.10 geschrieben und abgechickt habe. Danach bin ich vom Pc weggegangen, und jetzt habe ich entdeckt, dass das Posting fast 2 Stunden später ankam, sonderbar. Daher kommen in meinem Posting zum Teil ähnliche wie in Cheathas vor.

1. Halten meines Wissens viele dieser HTML-Chats einfach eine einzige Verbindung zu jedem User offen, und geben immer wieder etwas aus, so dass die Verbindung nie beendet wird, was nun eben dem Sinn von http widerspricht.

Eigentlich reicht es aber doch, dass sie entweder die neu angefallenden Chat-Daten uebertragen, oder, wenn nichts vorliegt, einen 204-Header. HTTP-Kopfdaten natuerlich in jedem Fall.

Dann wird es aber

Es mag sein, dass HTTP primaer anderen Zwecken dient und nicht gerade fuer diese Art der Client-Server-Kommunikation optimiert ist. Aber nicht von ungefaehr gibt es in Apache&Co. entsprechende Keepalive-Einstellungen. Es steht jedenfalls nirgendwo geschrieben, dass man maximal alle drei Minuten was von einem Webserver wollen darf ;-)

Keepalive ist meines wissens dafür gedacht, die erneute Verbindung bei mehreren gleichzeitigen Downloads von einem Server (Bilder etc.)

Wir haben hier ja einige unter uns (ich weiss nur nicht, ob jemand davon in diesem Thread mitliest), die auf http://www.kingchess.de/ ein SELF-Schachturnier ausgetragen haben. So weit ich weiss, wurde dabei auch fleissig im Chat von Kingchess gequatscht waehrend der Partien. Und von diesem Chat weiss ich, dass er einer dieser "boesen" Web-Chats ist. So weit ich aber auch weiss, verkehren dort deutlich mehr als 4-5 Leute, und dem Server scheints gut zu gehen. Klar, wenn 100 Leute chatten und jeder einen Apache-Prozess von 10MB im Speicher haelt, sind das 1BG, die der Apache RAM braucht fuer den Spass. Keine Frage.

Wieviel braucht ein IRC-Server für die gleichen Benutzermengen? Vielleicht 30 MB?

Weil ein Chat, der vom Layout her und im Browser ablaeuft, eben eher als zu einem Webangebot zugehoerig empfunden wird. Dieses Forum hier ist ja auch web-basiert. Der Grund ist, weil es zu einem Webangebot gehoert. Und wir leisten uns den Luxus, obwohl es den Server belastet, und obwohl wir ebensogut eine Mailingliste oder eine Newsgroup unterhalten koennten.

Man kann ja, wie man hier sieht, durchaus IRC über den Browser laufen lassen.
Ja, aber ein Forum hat gegenüber einer NG oder vor allem gegenüber einer Mailingliste viele Vorteile, wie einfacherer Zugang, bessere Durchsuchbarkeit, bessere Anpassung, Anfängerfreundlicher und auch bessere Ergebnisse in Suchmaschienen;-), anders als ein HTTP-Chat der viele Nachteile, wie viel Bandbreite, langsame Reaktionszeiten, schlechte Bedienung usw. gegenüber IRC hat.

mfg Andres Freund

[Michael Schröpl]

Hallo Stefan,

Eigentlich reicht es aber doch, dass sie entweder die neu angefallenden Chat-Daten uebertragen, oder, wenn nichts vorliegt, einen 204-Header. HTTP-Kopfdaten natuerlich in jedem Fall.

Eben. Und diese Kopfdaten sind das Teure - genau wie beim 50-Byte-GIF.

Klar, wenn 100 Leute chatten und jeder einen Apache-Prozess von 10MB im Speicher haelt, sind das 1BG, die der Apache RAM braucht fuer den Spass. Keine Frage.

Ein Apache-Prozeß bedient viel mehr als nur einen einzigen Client. Du hast natürlich nicht einen Prozeß pro Chat-Partner. (Sonst wäre der Server ja auf 256 gleichzeitige Besucher limitiert ... dann hättest Du ständig DOS-Situationen.)

Und überhaupt, was hast Du für einen Apache? Meiner belegt etwa ein Drittel davon - wirf doch mal die ganzen Module raus, die nicht gebraucht werden ...

3. Warum überhaupt benutzen, wenn es etwas viel effektiveres (IRC)gibt, was Traffic und Resourcen spart
   Weil ein Chat, der vom Layout her und im Browser ablaeuft, eben eher als zu einem Webangebot zugehoerig empfunden wird.

Eine Newsgroup auch - trotzdem wird diese einen eigenen News-Reader und das news-Protokoll verwenden und nicht das HTTP-Protokoll.

Was Du willst, das ist nicht ein Chat via HTTP, sondern ein IRC-Client in jedem Browser.
(Und eine Firewall-Konfiguration in allen Firmen, welche die IRC-Ports freigibt ... ;-(

Viele Grüße
      Michael

[Stefan Muenz]

Hallo Michael,

Ein Apache-Prozeß bedient viel mehr als nur einen einzigen Client. Du hast natürlich nicht einen Prozeß pro Chat-Partner. (Sonst wäre der Server ja auf 256 gleichzeitige Besucher limitiert ... dann hättest Du ständig DOS-Situationen.)

Siehst du, das hab ich gar nicht gewusst! Wo erfaehrt man denn so was - wieviele User von einem Apache-Prozess verwaltet werden?

Und überhaupt, was hast Du für einen Apache? Meiner belegt etwa ein Drittel davon - wirf doch mal die ganzen Module raus, die nicht gebraucht werden ...

Ich rede nicht von "meinem daheim", sondern von dem hier auf dem Server. Das top-Kommando weist derzeit ca. 11 MB pro Apache-Prozess aus.

Was Du willst, das ist nicht ein Chat via HTTP, sondern ein IRC-Client in jedem Browser.

Wie funktioniert eigentlich das IRC-Protokoll, bzw. wie schafft es seine Effizienz bei persistenten Verbindungen? Gibt es da nur Minimal-Header? Oder irgendwelche Geheimnisse, von denen ich bislang nicht mal zu traeumen wagte? ;-)
Und dann gibt es ja noch die Erweiterbarkeit von Webservern wie Apache. Klar bleibt man immer an den Grenzen von HTTP haengen. Aber erlaubt das Modulsystem von Apache nicht, auch mal ein Modul zu integrieren, dass fuer derartige Aufgaben optimiert ist?

viele Gruesse
  Stefan Muenz

[Michael Schröpl]

Hallo Stefan,

Ein Apache-Prozeß bedient viel mehr als nur einen einzigen Client. Du hast natürlich nicht einen Prozeß pro Chat-Partner. (Sonst wäre der Server ja auf 256 gleichzeitige Besucher limitiert ... dann hättest Du ständig DOS-Situationen.)
Siehst du, das hab ich gar nicht gewusst! Wo erfaehrt man denn so was - wieviele User von einem Apache-Prozess verwaltet werden?

Uh ... ich weiß auch nicht so recht ...

Hast Du mod_status und mod_info eingebunden? (Dumme Frage - sicher, wenn Du 11 MB ... ;-)

Sind beide auch konfiguriert? (Mapping eines URL auf den Aufruf des entsprechenden Handlers ... sinnvollerweise mit Authentifizierung geschützt ...)
   http://httpd.apache.org/docs/mod/mod_status.html
   http://httpd.apache.org/docs/mod/mod_info.html
Damit kannst Du im laufenden Betrieb in den Apache "hinein sehen".

Mit mod_status sieht man zumindest die Prozesse, das habe ich mal ausprobiert.
mod_info listet wohl nur die Module und Direktiven aus - das geht auch per Kommandozeile (siehe unten).

Und überhaupt, was hast Du für einen Apache? Meiner belegt etwa ein Drittel davon - wirf doch mal die ganzen Module raus, die nicht gebraucht werden ...
Ich rede nicht von "meinem daheim", sondern von dem hier auf dem Server. Das top-Kommando weist derzeit ca. 11 MB pro Apache-Prozess aus.

Das hier läuft bei uns produktiv auf der Serverfarm:

PID USERNAME THR PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND
29784 nobody     3  48    0 3944K 2968K sleep   0:01  0.00% httpd

(Ich überlege gerade, ob "THR" die Threads innerhalb des Prozesses sind ... Mist, "man top" tut nicht, das Produkt hat unser Solaris-Admin irgendwann mal schnell nachinstalliert ...)

/apache/current > bin/httpd -l
Compiled-in modules:
  http_core.c
  mod_env.c
  mod_log_config.c
  mod_mime.c
  mod_include.c
  mod_dir.c
  mod_cgi.c
  mod_actions.c
  mod_alias.c
  mod_access.c
  mod_auth.c
  mod_proxy.c
  mod_expires.c
  mod_headers.c
  mod_setenvif.c
  mod_gzip.c

(Das ist so "das Nötigste für den Hausgebrauch" - die httpd.conf habe ich allerdings radikal umgeschrieben. "configure" ist das Werkzeug, um hier 'abzumagern'.)

Wie funktioniert eigentlich das IRC-Protokoll

Keine Ahnung ... Google meint: RFC 1459 = http://www.irchelp.org/irchelp/rfc/rfc.html

bzw. wie schafft es seine Effizienz bei persistenten Verbindungen?

Eine Unterhaltung läuft viel flüssiger, wenn sich nicht jeder Teilnehmer vor jedem Satz ausführlich vorstellen muß. Bei einer stehenden Verbindung "kennt man einander". Das hilft. ;-)

Gibt es da nur Minimal-Header?

Wahrscheinlich bloß eine Session-ID, und einen Header für den aktuellen Befehl. Und beides womöglich noch binär codiert ...

Bei HTTP sendet der Browser ja seine volle Palette an Fähigkeiten mit,
[ 35] GET /cgi-bin/http_trace.pl HTTP/1.1
[ 20] ACCEPT_LANGUAGE: en
[ 18] CONNECTION: close
[ 12] ACCEPT: */*
[ 34] USER_AGENT: Mozilla/5.0 (rv:1.3b)
[ 19] HOST: 153.46.90.85
[ 22] ACCEPT_ENCODING: gzip
[ 47] ACCEPT_CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.7
für den Fall, daß ein hochintelligenter Server dann damit eine Negotiation durchführt ... was die wenigstens tatsächlich tun.
Je einfacher (und unflexibler) das Protokoll ist, um so weniger muß der Client über sich erzählen.

Und dann gibt es ja noch die Erweiterbarkeit von Webservern wie Apache. Klar bleibt man immer an den Grenzen von HTTP haengen. Aber erlaubt das Modulsystem von Apache nicht, auch mal ein Modul zu integrieren, dass fuer derartige Aufgaben optimiert ist?

Module regeln, was _innerhalb_ des Apache passiert - _außerhalb_ wird HTTP gesprochen.

Unsere Diskussion dreht sich um die Eignung von HTTP für das Problem - nicht um Apache.

Viele Grüße
      Michael

[Schuer]

Hallo,

Wir haben hier ja einige unter uns (ich weiss nur nicht, ob jemand davon in diesem Thread mitliest), die auf http://www.kingchess.de/ ein SELF-Schachturnier ausgetragen haben.

Ich lese gerade zufällig mit, verstehe aber als technischer Laie in dieser Hinsicht kein Wort von dem, was ihr da redet :-)

So weit ich aber auch weiss, verkehren dort deutlich mehr als 4-5 Leute, und dem Server scheints gut zu gehen.

Ich war nur einmal kurz im Kingchess-Chat, und er schien ganz gut zu funktionieren. Es sind definitiv mehr als 4-5 Leute, die dort verkehren. Laut Forum scheint es inzwischen einige Stammchatter zu geben, die regelmäßig online sind. Es hieß auch mal, dass es eine Art von Themenchats zu bestimmten Zeiten gibt, so dass man davon ausgehen kann, dass zu dieser Zeit sicherlich weit mehr als 5 User im Chat sein sollten.

Aber wie gesagt: Ich hab nur mal kurz reingeschnuppert und lese hin und wieder etwas im Forum. Ansonsten beschränke ich mich dort auf Schach spielen und vor allem Verlieren, wenn ich mit Leuten wie den beiden Romans, Mattes oder Wilhelm zu tun habe. Ach ja, und Siramon hat mich auch tierisch vom Brett gefegt.

Hüte dich vor den Schweizern! ;-)

Gruß,
_Dirk

[Michael Schröpl]

Hallo Stefan,

Und wer schreibt vor, dass immer nur komplette HTML-Seiten uebertragen werden muessen,
und nicht mal nur einzelne HTML-Strings?

Niemand. Aber es ist hochgradig unwirtschaftlich, einzelne HTML-Skripts mit HTTP zu übertragen.

HTTP erfordert sowohl für den Request als auch für die Response einen HTTP-Header.
Beim Request ist dieser bei handelsüblichen Browser-Konfigurationen 400-700 Bytes lang (wenn man sich bei der Browser-Konfiguration sehr gut auskennt, kann man ca. 50% davon einsparen: Cookies aus, Referer aus, User-Agent weg, wenn man sich traut, Language weg, wenn man nicht mit Negotiation rechnet, Accept- und Accept-Encoding-Listen kürzen etc. - beim M$IE steht das Zeug in der Registry, man kommt an ziemlich viel davon ran ... ich müßte eigentlich mal einen Feature-Artikel darüber schreiben ...), bei der Response etwa 200-300 Bytes (das liegt auf der Seite des Servers und dort an der Art der Antwort, d. h. es hängt teilweise auch von der Art der Frage ab).
Durch Cookies kann dieser Wert übrigens extrem in die Höhe gehen: Ein Cookie kann bis zu 4 kB Inhalt haben, und wenn das bei jedem Request hin und her geschickt werden muß ...
Hinzu kommt noch etwas Verpackung auf TCP/IP-Ebene ... wenn Du pro Request konservativ einen Overhead von 1 kB schätzt, liegst Du auf der sicheren Seite.
(OT: In mgzta ist dieser Wert konfigurierbar, weil Apache 1.3 ihn leider gar nicht erfassen kann - in Apache 2.0 soll das wohl gehen.)

Wenn Du eine HTML-Seite im Umfang von 10 kB über das Netz sendest, dann hast Du also immerhin fast 10% Verpackungs-Overhead. Bei großen Dateien wird das Verhältnis immer günstiger; bei kleinen Dateien (etwa den Markierungs-GIFs hier im Forum) wird es immer schlechter. Auch ein GIF-Bild von nur 50 Byte kostet 1000 Bytes Verpackung - satte 2000% Overhead also! Ich kenne kaum ein Ladezeit-Analyse-Werkzeug, das diese Werte in seiner Berechnung berücksichtigt ... aber viele kleine Bilder können eine Katastrophe sein, wenn der Browser sie alle einzeln anfordern muß.

Und schlimmer noch: Selbst ein "conditional GET" eines Browsers, also die Frage "ich habe hier einen Cache-Inhalt vom Datum X.Y - hast Du schon etwas Neueres, oder darf ich den weiter verwenden?" kostet immer noch dieselben 1000 Bytes - Du sparst gerade mal die 50 Bytes des Bildchens ein, nicht aber die übrigen 95% des Übertragungsvolumens.
Das ist der Grund, weshalb ich es für so wichtig halte, solche Bilder vom Browser "aggressiv" cachen zu lassen, also durch den Server eine Aufbewahrungsfrist zu senden, während welcher der Browser den Server _nicht_fragt_ (vorausgesetzt, der Browser ist richtig konfiguriert ... das sind leider natürlich auch nicht alle). Dies kostet zwar zusätzliche ca. 50-100 Bytes im Response-Header - aber wenn ich damit 20% aller Anfragen verhindern kann (in dieser Größenordnung lag der Effekt auf dem Self-Server, wo Christian das aktiviert hat), ist das eine gute Investition. (Vor allem wird das Surfen subjektiv schneller, weil sich die zeitliche Verteilung der HTTP-Requests ändert - _das_ ist ein "Preloading-Effekt".)

Und nein - HTTP-Header werden üblicherweise auch nicht komprimiert übertragen. Es gibt zwar wohl auf Modem-Ebene ein Protokoll, welches das kann, aber erstens unterstützt das nicht jeder ISP und zweitens sind die Informationen eines HTTP-Headers von begrenzter Redundanz, insbesondere sehr viel schlechter komprimierbar als HTML oder CSS: Innerhalb _eines_ HTTP-Headers wiederholt sich nichts.
(Ich habe hier ein "Labor" von HTTP-Request-Headern von ca. 20 Browsern und habe die gerade mal alle gezippt: Die Komprimierungsraten liegen zwischen 19% und 34%, während bei HTML 60-90% durchaus normal sind - wir haben schon Fälle von 97% gemessen, bei großen Tabellen ohne CSS ...)

Die gesendeten HTTP-Header sind _einander_ sehr ähnlich: Etwa 50-75% ihres Inhalts ist immer gleich. Aber HTTP hat ja kein Gedächtnis, deshalb kann man auch keine Deltas übertragen.
Hier ist eine stehende Verbindung (welche diesen immer gleichen Teil natürlich auf dem Server cachen würde) grundsätzlich überlegen, wenn viele kleine Anforderungen übertragen werden sollen.

Wenn Du pro Chat-Posting einen Mittelwert von ca. 100 Bytes annimmst, dann hast Du einen mittleren Verpackungs-Overhead von 1000%. Das kann's nicht sein.

aber warum jemand tobt, wenn ueber ein zustandsloses Protokoll doch noch eine Art
Quasi-Verbindung (z.B. ueber intervallische Aufrufe) realisiert wird, kann ich daran
keine Vergewaltigung erkennen.

Jetzt immer noch nicht? ;-)

Viele Grüße
      Michael

[Stefan Muenz]

Hallo Michael,

schoen, mal wieder miteinander zu tun zu haben :-)

Beim Request ist dieser bei handelsüblichen Browser-Konfigurationen 400-700 Bytes lang (wenn man sich bei der Browser-Konfiguration sehr gut auskennt, kann man ca. 50% davon einsparen

Also ich will ja nicht den Alles-Peanuts-Typen raushaengen lassen - aber diese Datenmenge erscheint mir angesichts dessen, was so alles pro Sekunde durch die Leitungen fliesst, nicht so besonders dramatisch zu sein. Angenommen, alle 10 Sekunden wird je ein Request und ein Response von 700 Byte zwischen einem Client und einem Server getaetigt: dann sind das 8,2 Kilobyte pro Minute oder 492 Kilobyte pro Stunde. Dazu die Nutzdaten - bei einem typischen Themenchat der SELF-Developer kommen wir mit ca. 12-15 Leuten auf nicht mal 50 Kilobyte Text pro Stunde, obwohl wir uns angeregt unterhalten. Also ich finde das alles durchaus nicht uebertrieben. Auch wenn das Verhaeltnis von Nutzdaten und Keepalive-Daten dann 1:10 betraegt.

Jetzt immer noch nicht? ;-)

Nein - ehrlich gesagt nicht. Denn bei diesen moderaten Gesamtdatenmengen (im Vergleich: wenn man viel auf normalen Business-Seiten rumsurft, kommt man locker auf das 10 fache in der Stunde) ist es mir eigentlich nicht so wichtig, wie das Verhaeltnis zwischen Nutz- und Headerdaten ist. Sicher koennte es besser sein. Aber ein Mensch mit einen 0,irgendwas PS kann mit einem Fahrrad problemlos 20 Sachen im Schnitt fahren. Ein Auto, das 200 im Schnitt faehrt, braucht aber viel mehr als das 10fache an PS davon. Trotzdem fahren die Leute so viel Auto ;-)

viele Gruesse
  Stefan Muenz

[Michael Schröpl]

Hallo Stefan,

schoen, mal wieder miteinander zu tun zu haben :-)

tja, DSL verändert mein Leben ...

Also ich will ja nicht den Alles-Peanuts-Typen raushaengen lassen - aber diese Datenmenge erscheint mir angesichts dessen, was so alles pro Sekunde durch die Leitungen fliesst, nicht so besonders dramatisch zu sein.

Bevor uns letztes Jahr ein Projekt aufgrund dieses Effekts gescheitert ist, weil die Kosten für einen Großkunden plötzlich hundertmal so hoch geworden wären wie zuvor, bloß weil die Börsenkurslisten nicht per Mausklick, sondern per automatischem Refresh aktualisiert werden sollten (wir haben das tatsächlich implementiert, es funktionierte aber nur unter Laborbedingungen ... lustigerweise war gar nicht die Leitung das Problem, sondern der Datenbankserver brach wegen der verhundertfachten Requests zusammen ... der Apache hätte es geschafft ;-), dachte ich auch, die paar kB würden es nicht reißen.
(Wir _haben_ natürlich das alternative Kommunikationsmodell als Produkt, aber das erfordert die Installation unserer Client-Software auf dem PC des Anwenders ... und Java oder gar ActiveX lassen die Firewalls unserer sicherheitsbewußten Kunden üblicherweise nicht durch.)

Angenommen, alle 10 Sekunden wird je ein Request und ein Response von 700 Byte zwischen einem Client und einem Server getaetigt:

Ist Dir das schnell genug bei einem Chat? (Wäre es Dir schnell genug bei Börsenkursen?)

dann sind das 8,2 Kilobyte pro Minute oder 492 Kilobyte pro Stunde.

Genau. Und der Chatter geht dann zum Mittagessen und läßt sein Programm natürlich eingeschaltet, weil er über die Firmen-Standleitung sowieso online ist ... jetzt mach das mal mit ein paar Tausend Anwendern. :-(

Also ich finde das alles durchaus nicht uebertrieben. Auch wenn das Verhaeltnis von Nutzdaten und Keepalive-Daten dann 1:10 betraegt.

Es ist ja nicht unmöglich - es ist nur falsch[tm].
Und es gibt Chats mit viel mehr Besuchern als den elitären Kreis der Selfer ... ;-)

im Vergleich: wenn man viel auf normalen Business-Seiten rumsurft, kommt man locker auf das 10 fache in der Stunde

Dabei gilt aber das Verursacherprinzip: Du _willst_ diese Information haben.

Beim Chat machst Du Requests, obwohl Du gar nicht weißt, ob Du Information zurück bekommst - das ist einfach vom Prinzip her verkehrt.
Beim Chat _muß_ der Server die Initiative haben, weil nur der weiß, wie die vorhandenen Ressourcen sinnvoll auszunutzen sind. Und damit scheidet HTTP aus, weil HTTP nicht "senden" kann - es kann nur "antworten".

Aber ein Mensch mit einen 0,irgendwas PS kann mit einem Fahrrad problemlos 20 Sachen im Schnitt
fahren. Ein Auto, das 200 im Schnitt faehrt, braucht aber viel mehr als das 10fache an PS davon.

Wenn Du ein Auto mit demselben Gewicht wie ein Fahrrad als Vergleichswert nimmst, dann stimmt Deine Rechnung aber nicht mehr.

Trotzdem fahren die Leute so viel Auto ;-)

Und? Findest Du das richtig?
Würden die Menschen heute noch in Fahrrad-Reichweite ihres Arbeitsplatzes wohnen können ...
(Und überhaupt: Auf welcher Straße fährt ein Auto 200 _im_Schnitt_?)

Viele Grüße
      Michael

(der seine 80km ins Büro und zurück per Auto fährt, weil öffentliche Nahverkehrsverbindungen pro Tag zwei Stunden länger dauern würden ... und das zwischen Landeshauptstadt und Banken-Metropole)