Long polling mit Threads und sleep() = gute Idee?

[Onyxagargaryll]

Hallo zusammen!

Ich habe mir mal überlegt, ob es gescheiter wäre, ein PvP-Duellsystem mit normal polling oder long polling/comet & sleeps zu machen. Hier mal meine Überlegungen:

Normal polling:
Request z.B. alle 2 Sekunden. HTTP, auswerten, etc. (Muss ich hier nicht genauer ausführen...)

Long polling:
Funktionsweise: db-check, sleep(2000), db-check, sleep(2000), etc.
Bis die Daten zur Verfügung stehen.
Für jeden solchen Client wird vom Apache ein Thread (child process (Unix)) erstellt und gescheduled. Ein Kollege hat mal bei sich auf dem Laptop festgestellt, dass das Schedulen bei bereits 300 Threads überhand nimmt (ich habe ähnliche HW-Ressourcen auf dem Server). Er benutzte jedoch kein sleep() von PHP - wahrscheinlich macht das aber keinen Unterschied (oder?)

Meine Frage: Was ist "besser"? Dabei geht es vor allem um Performance (es sei denn, letzteres ist z.B. gar nicht möglich - es sieht aber soweit nach einer validen Lösung aus)

Würde mich sehr über fachlichen Input freuen!

Gruss
Onyx

[Onyxagargaryll]

Why this doesn't work

Sooo ich hab das mit ein paar Kollegen diskutiert, dabei ist herausgekommen dass mein Vorhaben an Folgendem scheitern wird:
Ein Apache-Prozess/-Thread belegt immens viel Speicher, bei mir war das 18MB+ pro Thread! Ihr könnt euch also denken, dass damit ziemlich schnell Grenzen erreicht werden. sleep() bietet also keine direkte Möglichkeit, sondern man müsste das z.B. über comet frameworks oder application servers (und Technologien) lösen (z.B. nodejs, Tornado, usw).

Hoffe das hilft, falls jemand anderes auch mal auf das Problem stösst.

Haltet euch nicht zurück mit Kommentaren falls ich was falsch sehe!

[combie]

Auch in PHP läßt sich ein (http) Daemon schreiben.
Dabei ist die Funktion socket_select() bestimmt sehr hilfreich.
Und auch ein sleep() an passender Stelle macht dann Sinn.

Benötigt werden dazu allerdings weitgehende Rechte auf dem Server.