[php] Performanter php Chat

[Daniel Lorch]

hi,

> Aber es waere eine Idee, man koennte dann Threads als
> PHP-Sonderheft herausgeben, mit allen Zuschriften und
> dem vollstaendigen Namen der Autoren ... ;-)

Jo, wär was. phpbar.de in Druckform.

> oops,
> man muss mindestens zwei Anwendungsfaelle trennen:
> A - der 'kleine' Chat fuer einen Freundeskreis,
>     so bis maximal ein Dutzend 'ruhige' User.

uhm halt. Weiter vorne im Thread hat ja jemand den Term "HTTP Streaming" er-
funden. Gemeint sein soll, dass der Browser die Verbindung zu einem Script
offen hält anstatt zu "pollen" und sukzessive ein Script hämmern. Das klingt
Webserver-freundlicher, ist es aber nicht.

Apache hat eine Direktive namens "MaxClients". Diese ist per Default auf 256
gestellt. Um das Manual zu zitieren:

  "The MaxClients directive sets the limit on the number of simultaneous
  requests that can be supported; .."

Lässt Du also Dein Chat-Script auf einem shared Hoster laufen, blockierst
Du alleine ein Dutzend Verbindungen. Wird der Chat etwas populärer gelangt
der Webserver an die Grenzen - nicht wegen zu viel Load, zu viel Traffic
oder sonstwas, sondern weil er keine weiteren Verbindungen mehr öffnen
kann. HTTP-Verbindungen sind "stateless" und darauf ist die Einstellung
nun mal optimiert.

Aus diesem Grund werden für "PHP-Chats", wie z.B. ircg seperate, für diesen
Zweck optimierte Webserver eingerichtet.

> B - den 'professionellen' Chat fuer richtigen Traffik.

Es ist nicht (nur) der Traffic.

> Fall B braucht eine ausgefeilte Loesung und eine eigene
> Maschine.

S'geht. Was tut Chat schon? Nimmt Deine Message und verteilt sie an alle. Was
ist daran CPU-intensiv. Das ist hauptsächlich i/o.

> Aber das ist reine Theorie, weil auf keiner Maschine,
> auf die ich bislang Zugriff hatte, PHP-IPC ueberhaupt
> moeglich war ... :-(

Ok, dann halt nochmals :)

  http://www.php.net/shmop
  http://www.php.net/sem

-daniel