Hallo Thomas,
Thomas Schmidt wrote:
Hallo Eric!
Nun gibt es ja aber Seiten, die so tun, als wären Sie (Achtung, Buzzword) "Rich Clients" und daher permanent den Server befragen, ob irgendein Ereignis zu verarbeiten ist. Quasi simulieren die damit GUI-Events durch Polling. Das klingt ja an sich schon nach großem Mist, da ja doch wieder unnötige Daten übertragen werden.
Das ist immer das Problem bei Polling. Aber es ist eben eine einfache Lösung, um gewissen Dinge möglich zu machen, wenn zum Beispiel die Gegenrichtung (Server-Push gibt's ja auch bei HTTP, aber das ist in dem Zusammenhang eher schwierig umzusetzen und vor allem nicht so breit von den Browsern unterstützt) nicht so ohne weiteres machbar ist...
Belegt damit der Client nicht permanent einen httpd-Prozess für das Polling? Oder wird das z.B. vom Apache irgendwie effizienter abgewickelt? Ansonsten dürften ja einige wenige dutzend Benutzer den Webserver an seine Speichergrenzen treiben, wenn da soviele httpds beschäftigt sind, oder nicht?
Richtig. Es kommt auf die Keepalive-Time des Apache an. Wenn der wie in der Standardeinstellung 30 Sekunden wartet, ob der Client noch etwas will, wird für jeden User ein Apache fällig. Hat der Apache dann noch die ganzen Module und PHP-Interpreter, sind 15-20 MB RAM pro Person am Arsch.
Das ist allerdings jetzt wieder nur die Hälfte der Wahrheit, weil zum Beispiel Linux auch beim fork() ein Copy-On-Write macht. Wenn da ein Apache "theoretisch" mit 15 MB zu Buche schlägt, aber die Mehrzahl der Module garnicht benutzt wird, dann sieht der Prozeß zwar groß aus, aber im Prinzip hat der zugehörige Prozeß statt einer ganzen Speicherseite im Hauptspeicher nur einen Verweis auf dieselbe Speicherseite des Parent-Prozesses (bis eben in dem Bereich geschrieben wird, dann wird die Seite kopiert). Da wird nicht ganz so viel gebraucht, wie es zunächst den Anschein hat. Es ist dann halt die Frage, was die Requests dann so an Speicher wirklich beschreiben und was nicht...
Thomas
Ciao, Thomas