Eventlet ist eine von SecondLife geschriebene Netzwerk-Bibliothek für nicht-blockierendes IO, welchem allgemein eine höhere Skalierbarkeit nachgesagt wird, als blockierendes IO. Leider kommt diese Skalierbarkeit zu einem hohen Preis. Der Code ist komplexer und die reaktive Programmierung (wie z.B. bei Twisted) schwerer verständlich. Eventlet nutzt die Greenlet-Bibliothek für Coroutinen, die ein einfacheres Programmiermodell bieten sollen.
Ein `easy_install eventlet` zieht greenlet-0.2 und pyOpenSSL-0.9 als Abhänigkeiten.
Spawning ist ein WSGI unterstützender HTTP-Server basierend auf Eventlet. Er soll sowohl mehrere Prozesse als auch mehrere Threads unterstützen können und damit effizient(er) moderne Mehrkernprozessoren unterstützen. Da er dank nicht-blockierender Sockets viele Verbindungen gleichzeitig offen halten kann, müsste er insbesondere für Ajax/Comet-Anwendungen geeignet sein.
Ein `easy_install spawning` zieht PasteDeploy-1.3.3 und simplejson-2.0.9 als Abhängigkeiten (auch obwohl ich Python 2.6.2 habe und da eigentlich SimpleJson unnötig wäre).
Stefan
Hat jemand schon mal Eventlet und/oder Spawning eingesetzt?
Diese WSGI-Anwendung läuft direkt mit Eventlet:
Ein einfaches `ab -c 100 -n 1000` zeigt aber keine Verbesserung gegenüber der Python-WSGI-Referenzimplementierung. Und `ab -c 100 -n 5000` schaffen beide nicht. Ich überflute damit offenbar den Server mit Requests, die nicht schnell genug angenommen werden können.
Gleiches gilt leider für Spawning ohne weitere Angaben. Setze ich die Threads auf 50, schaffe ich `ab -c 100 -n 5000` manchmal. Erst wenn ich vom 1 auf 2 Prozesse gehe (die dann offenbar jeder 10 Threads haben), schaffe ich's zuverlässig. Threads allein helfen also kaum. Erst mehrere Prozesse nehmen zuverlässig alle Requests an. Enttäuschend.
Mit 5 Prozessen und 50 Threads schaffe ich ca. 1000 R/s bei 96ms/R.
Im Vergleich dazu Glassfish v3 (Grizzly) unter Java 5 (Server-Mode): ca. 4000 R/s bei 25ms/R. Möglicherweise messe ich hier aber auch nur, wie schnell mein Notebook Log-Dateien schreiben kann...
Pythons Zeiten entarten auch extrem, was für mich ein Indiz ist, das der Server überlastet ist. Der langsamste R ist hier 24x langsamer als der schnellste. Glassfish's langsamster R ist nur 2x langsamer. Glassfish hat auch keine Probleme mit noch mehr Requests. Ob Jetty oder Tomcat besser oder schlechter sind oder ob man Glassfish noch tunen müsste, habe ich nicht geprüft.
Leider muss ich sagen, habe ich bei Java mehr Vertrauen in eine einfach und plattformübergreifend deploybare Lösung als bei Python. Muss dringend noch mal Jython ausprobieren.
Stefan
Code: Alles auswählen
def application(environ, start_response):
start_response("200 OK", [('Content-type', 'text/html')])
return ["Hallo, Welt"]
if __name__ == '__main__':
from eventlet.api import tcp_listener
from eventlet.wsgi import server
server(tcp_listener(('0.0.0.0', 8000)), application)
Gleiches gilt leider für Spawning ohne weitere Angaben. Setze ich die Threads auf 50, schaffe ich `ab -c 100 -n 5000` manchmal. Erst wenn ich vom 1 auf 2 Prozesse gehe (die dann offenbar jeder 10 Threads haben), schaffe ich's zuverlässig. Threads allein helfen also kaum. Erst mehrere Prozesse nehmen zuverlässig alle Requests an. Enttäuschend.
Mit 5 Prozessen und 50 Threads schaffe ich ca. 1000 R/s bei 96ms/R.
Im Vergleich dazu Glassfish v3 (Grizzly) unter Java 5 (Server-Mode): ca. 4000 R/s bei 25ms/R. Möglicherweise messe ich hier aber auch nur, wie schnell mein Notebook Log-Dateien schreiben kann...
Pythons Zeiten entarten auch extrem, was für mich ein Indiz ist, das der Server überlastet ist. Der langsamste R ist hier 24x langsamer als der schnellste. Glassfish's langsamster R ist nur 2x langsamer. Glassfish hat auch keine Probleme mit noch mehr Requests. Ob Jetty oder Tomcat besser oder schlechter sind oder ob man Glassfish noch tunen müsste, habe ich nicht geprüft.
Leider muss ich sagen, habe ich bei Java mehr Vertrauen in eine einfach und plattformübergreifend deploybare Lösung als bei Python. Muss dringend noch mal Jython ausprobieren.
Stefan
[einen habe ich noch, wollte das Posting thematisch aufteilen]
Rubys in Ruby geschriebener Webrick-Server schafft bei dieser Rack-Anwendung (Rack == WSGI für Ruby)
weder `ab -c 100 -n 1000` noch sonst was größer `-c 10`. Damit dann 220 R/s bei 45ms/R. Hämisches Grinsen ist hier erlaubt.
Nutze ich Thin, der ähnlich wie Spawning nicht-blockierendes IO benutzt, wird's besser:
100 parallele Requests sind wie bei Python kein Problem mehr: 880 R/s und 112ms pro R. Die R-Zeiten entarten außerdem nicht und wie bei Glassfish ist nach oben noch Luft. Thin erfordert dabei keine besondere Konfiguration und scheint auch nur einen Prozess mit einem Thread zu benutzen.
Übrigens, die Debug-Webseite von Rack erinnert mich irgendwie total an Django :)
Stefan
Rubys in Ruby geschriebener Webrick-Server schafft bei dieser Rack-Anwendung (Rack == WSGI für Ruby)
Code: Alles auswählen
run lambda { |env| [200, { 'Content-Type' => 'text/html' }, 'Hello World'] }
Nutze ich Thin, der ähnlich wie Spawning nicht-blockierendes IO benutzt, wird's besser:
100 parallele Requests sind wie bei Python kein Problem mehr: 880 R/s und 112ms pro R. Die R-Zeiten entarten außerdem nicht und wie bei Glassfish ist nach oben noch Luft. Thin erfordert dabei keine besondere Konfiguration und scheint auch nur einen Prozess mit einem Thread zu benutzen.
Übrigens, die Debug-Webseite von Rack erinnert mich irgendwie total an Django :)
Stefan