Das kommt auf ein Einsatzzweck an. Tornado und co. sind darauf optimiert Anfragen ohne Last offen zu halten, und nur Speicher und CPU Zeit zu verbrauchen, wenn wirklich etwas passiert. Tornado kann leicht 10'000 Verbindungen offen halten, das ist für Apache so nur schwer möglich. Passiert etwas auf einer Verbindung, so wird dies verarbeitet, danach ruht sie wieder. Das ist z.B. auch dann nützlich, wenn der Webserver auf verschiedene externe Quellen (Datenbankserver, LDAP usw.) wartet. In dieser Zeit tut er einfach nichts mit der Verbindung. Apache und co. verbrauchen in solchen Situationen meist pro Verbindung CPU Zeit und ordentlich Arbeitsspeicher.
Für normale Webseiten, die nicht angepasst sind, ist das jedoch meist von keinerlei Vorteil, da die Software selbst nicht entsprechend darauf ausgelegt ist. Optimal arbeitet es, wenn viele Verbindungen aktionsfrei offen gehalten werden müssen (Chats), oder wenn die Verarbeitung der Anfrage von "langsam" externen Quellen abhängt (komplexe Webseiten) deren resultate idealerweise in loser Reihenfolge abgearbeitet werden können sobald sie eben eintreffen.
Warum nimmt man dafür kein C (oder von mir aus auch C++) mit bspw. libevent, welche exakt für Szenarien mit u.a. epoll und kqeue ausgelegt ist, sondern setzt auf den Overhead einer Skriptsprache? Das soll keine Anregung zum einem Flamewar werden, mich würde die nur Intention der Entwickler interessieren.
Ich denke das Performanceproblem das hier angegangen wird hat nichts mit dem "Overhead" einer Skriptsprache zu tun, sondern ist konzeptioneller, programmiertechnischer Art (warten auf eine Verbindung oder vom System über eine neue Verbindung informiert werden.) Insofern ist es natürlich komfortabler auf eine Skriptsprache zu setzen, da der Code mit epoll tendenziell komplexer wird, eine gute Skriptsprache diese Komplexität aber im Vergleich zu C/C++ reduzieren kann. libevent stellt im übrigen, wenn ich das richtig verstanden habe, nur eine Abstraktionsschicht für verschiedene event-basierte Methoden. Bei einer Neuentwicklung bei der sich für eine bestimmte Technik entschieden wurde ist das nicht zwingend Notwendig.
Das ganze ist meine Interpretation der Dinge. Im Grunde hab ich aber keine Ahnung.
Sehr schöne Seite noch zum Thema: http://scotdoyle.com/python-epoll-howto.html
Ich denke, hier geht es eher um das Problem der Parallelisierung von Anfragen, da spielt der Overhead einer Skriptsprache, deren Bytecode-interpreter vielleicht schon dauernd im Hintergrund läuft kaum eine Rolle. Vielleicht haben Skriptsprachen durch eingebaute Microthreads und ähnliche Mechanismen sogar Vorteile. Wenn dies so problematisch wäre, hätten sich PHP und Erlang in ihren Bereichen möglicherweise gar nicht durchgesetzt.
Wäre das in Erlang geschrieben, hätte ich auch so argumentiert, aber Python. Pythons Vorzüge liegen eher in der Lesbarkeit/Wartbarkeit als in der Geschwindigkeit.
Eben. Und wenn es nicht grad um Numbercrunching geht, ist Python für viele Aufgaben eben schnell genug. Letztlich kann man immer für oder gegen die Wahl einer Sprache argumentieren: Fakt ist aber doch, dass das Ergebnis funktioniert!
Spekulationen, ob das ganze nicht performanter in einer anderen Sprache gewesen sei, lassen sich leicht beweisen: Man muss es nur implementieren
Erlangs Stärke ist ebenfalls die Nebenläufigkeit und nicht die reine Gewschwindigkeit. Anders herum sind heutige Server einfach wegen dem PHP-Overhead so overpowerd, da spielt Python kaum eine Rolle.
Pythons Schwäche ist aber die Nebenläufigkeit. Entweder stört man sich auf GIL oder man nutzt Prozess Forken, was bei vielen und häufigen Wechseln langsam ist. Abgesehen davon gibts einige Spracheigenschaften die im Python konzeptionell bedingt immer langsamer sind als anderswo.
Die Vorteile von C/C++ sind hier nicht von belang, da Tornado vor allem für Szenarien ausgelegt ist, in denen der Webserver lange bei bestehenden Verbindungen idled. Das kann Python genauso gut wie C ;) Wenn dann aber etwas zu tun ist, ist das in Python bequemer zu erledigen.
Die meisten Anwendungen auf solchen Webservern, auch node.js, sind oft ziemlich winzig, da sie eine sehr spezielle Aufgabe erfüllen.
Meiner Erfahrung nach werden sie vor allem als Schnittstelle von User zum Backend genutzt, wo die eigentliche Arbeit geschieht.
Von gehtauchschneller am Do, 23. Juni 2011 um 10:25 #
Es gibt noch andere Möglichkeiten nen flotten Webserver zu bekommen ohne gleich mit C oder C++ anfangen zu müssen oder sich mit dem Overhead von Python herumzuärgern. Beispielsweise programmiert sich Go ähnlich einfach wie Python und ist dazu noch deutlich performanter, da nativer Code erzeugt wird. Außerdem muss man sich nicht mit Polling u.ä. auseinandersetzen denn da gibt's entsprechende Sprachmittel + Bibliotheken um das deutlich zu vereinfachen: http://ziutek.github.com/web_bench/
Für den Einsatzzweck von Tornado ist Python absolut ok in Sachen Geschwindigkeit, 99% der Zeit gehen eh im Netzwerk, im Betriebsystem & Hardware sowie im Backend (Datenbanken, Webservice usw.) drauf. Zudem muss sich auch niemand bei Tornado mit Polling und co. rumärgern, das macht ja Tornado bereits.
Wer noch mehr Eventbassierte Verarbeitung will, der nimmt z.B. Node.js (ja, Javascript), das ist dann eine Geschmacksfrage was man am ehesten mag.
Abgesehen davon schlägt sich doch Tornado sehr gut in den Benchmarks die du verlinkt hast. Wie der autor schon sagt "It surprised me the very high performance of tornado framework.". Das geht vielen oft so, Tornado ist wirklich fix, und das bei Beibehaltung von python und seinen Möglichkeiten.
Bin mal gespannt, wann uu.de darauf umstellt. Die Seiten gehen seit dem Einsatz von Tornado gefühlt wirklich flotter.
Und welche technische Konstruktion ist genau für diese Verbesserung z.B. gegenüber Apache verantwortlich?
Das kommt auf ein Einsatzzweck an. Tornado und co. sind darauf optimiert Anfragen ohne Last offen zu halten, und nur Speicher und CPU Zeit zu verbrauchen, wenn wirklich etwas passiert.
Tornado kann leicht 10'000 Verbindungen offen halten, das ist für Apache so nur schwer möglich. Passiert etwas auf einer Verbindung, so wird dies verarbeitet, danach ruht sie wieder.
Das ist z.B. auch dann nützlich, wenn der Webserver auf verschiedene externe Quellen (Datenbankserver, LDAP usw.) wartet. In dieser Zeit tut er einfach nichts mit der Verbindung. Apache und co. verbrauchen in solchen Situationen meist pro Verbindung CPU Zeit und ordentlich Arbeitsspeicher.
Für normale Webseiten, die nicht angepasst sind, ist das jedoch meist von keinerlei Vorteil, da die Software selbst nicht entsprechend darauf ausgelegt ist. Optimal arbeitet es, wenn viele Verbindungen aktionsfrei offen gehalten werden müssen (Chats), oder wenn die Verarbeitung der Anfrage von "langsam" externen Quellen abhängt (komplexe Webseiten) deren resultate idealerweise in loser Reihenfolge abgearbeitet werden können sobald sie eben eintreffen.
Warum nimmt man dafür kein C (oder von mir aus auch C++) mit bspw. libevent, welche exakt für Szenarien mit u.a. epoll und kqeue ausgelegt ist, sondern setzt auf den Overhead einer Skriptsprache? Das soll keine Anregung zum einem Flamewar werden, mich würde die nur Intention der Entwickler interessieren.
Ich denke das Performanceproblem das hier angegangen wird hat nichts mit dem "Overhead" einer Skriptsprache zu tun, sondern ist konzeptioneller, programmiertechnischer Art (warten auf eine Verbindung oder vom System über eine neue Verbindung informiert werden.)
Insofern ist es natürlich komfortabler auf eine Skriptsprache zu setzen, da der Code mit epoll tendenziell komplexer wird, eine gute Skriptsprache diese Komplexität aber im Vergleich zu C/C++ reduzieren kann.
libevent stellt im übrigen, wenn ich das richtig verstanden habe, nur eine Abstraktionsschicht für verschiedene event-basierte Methoden. Bei einer Neuentwicklung bei der sich für eine bestimmte Technik entschieden wurde ist das nicht zwingend Notwendig.
Das ganze ist meine Interpretation der Dinge. Im Grunde hab ich aber keine Ahnung.
Sehr schöne Seite noch zum Thema:
http://scotdoyle.com/python-epoll-howto.html
Ich denke, hier geht es eher um das Problem der Parallelisierung von Anfragen, da spielt der Overhead einer Skriptsprache, deren Bytecode-interpreter vielleicht schon dauernd im Hintergrund läuft kaum eine Rolle. Vielleicht haben Skriptsprachen durch eingebaute Microthreads und ähnliche Mechanismen sogar Vorteile.
Wenn dies so problematisch wäre, hätten sich PHP und Erlang in ihren Bereichen möglicherweise gar nicht durchgesetzt.
Wäre das in Erlang geschrieben, hätte ich auch so argumentiert, aber Python.
Pythons Vorzüge liegen eher in der Lesbarkeit/Wartbarkeit als in der Geschwindigkeit.
Eben. Und wenn es nicht grad um Numbercrunching geht, ist Python für viele Aufgaben eben schnell genug. Letztlich kann man immer für oder gegen die Wahl einer Sprache argumentieren: Fakt ist aber doch, dass das Ergebnis funktioniert!
Spekulationen, ob das ganze nicht performanter in einer anderen Sprache gewesen sei, lassen sich leicht beweisen: Man muss es nur implementieren
Erlangs Stärke ist ebenfalls die Nebenläufigkeit und nicht die reine Gewschwindigkeit. Anders herum sind heutige Server einfach wegen dem PHP-Overhead so overpowerd, da spielt Python kaum eine Rolle.
Pythons Schwäche ist aber die Nebenläufigkeit.
Entweder stört man sich auf GIL oder man nutzt Prozess Forken, was bei vielen und häufigen Wechseln langsam ist.
Abgesehen davon gibts einige Spracheigenschaften die im Python konzeptionell bedingt immer langsamer sind als anderswo.
Man kann ja Jython nehmen, ich sehe hier nicht das Problem.
"Pythons Schwäche ist aber die Nebenläufigkeit"
Stimmt, allerdings haben das die Leute von Tornado gut im Griff. In den Einsatzszenarien von Tornado ist das unwesentlich.
jython wurde ja zudem als Alternative genannt, wobei mir keine Erfahrungsberichte im Zusammenhang mit Tornado bekannt sind.
Die Vorteile von C/C++ sind hier nicht von belang, da Tornado vor allem für Szenarien ausgelegt ist, in denen der Webserver lange bei bestehenden Verbindungen idled. Das kann Python genauso gut wie C ;)
Wenn dann aber etwas zu tun ist, ist das in Python bequemer zu erledigen.
Die meisten Anwendungen auf solchen Webservern, auch node.js, sind oft ziemlich winzig, da sie eine sehr spezielle Aufgabe erfüllen.
Meiner Erfahrung nach werden sie vor allem als Schnittstelle von User zum Backend genutzt, wo die eigentliche Arbeit geschieht.
Es gibt noch andere Möglichkeiten nen flotten Webserver zu bekommen ohne gleich mit C oder C++ anfangen zu müssen oder sich mit dem Overhead von Python herumzuärgern. Beispielsweise programmiert sich Go ähnlich einfach wie Python und ist dazu noch deutlich performanter, da nativer Code erzeugt wird. Außerdem muss man sich nicht mit Polling u.ä. auseinandersetzen denn da gibt's entsprechende Sprachmittel + Bibliotheken um das deutlich zu vereinfachen:
http://ziutek.github.com/web_bench/
Für den Einsatzzweck von Tornado ist Python absolut ok in Sachen Geschwindigkeit, 99% der Zeit gehen eh im Netzwerk, im Betriebsystem & Hardware sowie im Backend (Datenbanken, Webservice usw.) drauf.
Zudem muss sich auch niemand bei Tornado mit Polling und co. rumärgern, das macht ja Tornado bereits.
Wer noch mehr Eventbassierte Verarbeitung will, der nimmt z.B. Node.js (ja, Javascript), das ist dann eine Geschmacksfrage was man am ehesten mag.
Abgesehen davon schlägt sich doch Tornado sehr gut in den Benchmarks die du verlinkt hast. Wie der autor schon sagt "It surprised me the very high performance of tornado framework.".
Das geht vielen oft so, Tornado ist wirklich fix, und das bei Beibehaltung von python und seinen Möglichkeiten.