Tutorial zu FCGI gesucht

[Reiner]

Hallo Andreas,

ich tüftel gerade an etwas, was eine sehr kurze Antwortzeit des Servers erfordert. Ziel ist es, bei einer dynamischen Anwendung ähnliche Antwortzeiten wie bei stat. Contens hinzubekommen.

Das kannst Du wohl vergessen ;-)

Ich sagte "ähnlich"! :-)

Ich denke das effizienteste wäre Deine Anforderung in einem eigenen Server-Modul zu implementieren.

Dabei bin ich jetzt so weit, daß ich mir zunächst einmal angesehen habe, welche Antwortzeiten bzw. Latencen ich bei statischem Content habe. Ich komme bei einem Apache2 auf ziemlich genau 30 Requests/Sekunde. Das ist schonmal gut.

Naja... ich würde mir bei Deiner Anforderung ernsthaft überlegen, von Apache abzusehen. Ich selbst würde es auf jeden Fall mit lighttpd versuchen, der ist vor allem bei statischem Content dem Apachen um Längen überlegen. Weitere Vorteile sind eben die besonders einfache Einbindung von FastCGI (das ist beim Apachen wirklich deutlich komplizierter), und nicht zuletzt die einfachere API für eigene Module.

Auch eine gute Idee.
Ich bin nicht auf den Indianer angewiesen! Es geht um eine Lösung des Problems, sehr hohe Geschwindigkeiten hinzubekommen, nicht eine bestimmte Art der Lösung!

Zudem habe ich mal probehalber ein Script geschrieben, was Content einmal per perl und einmal per php ausliefert. Dabei wird eine Schleife durchlaufen, die rel. groß ist.
Ich bin mir sicher, daß das vielleicht nicht direkt vergleichbar ist, aber bei mir kam heraus, daß perl ca. 3mal schneller als php ist.

Beides CGI? Ist zwar ungewöhnlich in dem Ausmaß, aber solche synthetischen Benchmarks sagen ja auch nicht wirklich viel aus. Wäre mal interesant den jeweiligen Code zu sehen.

Nee, einfach nur auf der Konsole ausgeführt Schleife.
Wie gesagt, sicher nicht repräsantativ, aber php scheint schon um Länger langsamer zu sein.

Nächster Flaschenhals (und darauf bezieht sich meine eigentliche Frage) wäre, daß das Script bei jedem Aufruf neu geladen wird, was sicher auch Zeit kostet.
Gut, bei mod_php und mod_perl hast Du ja wenigstens schonmal das Laden des Interpreters bei jedem Request gespart, bei PHP kannst Du das Laden des Scriptes mit Opcode-Caches wie eAccelerator, oder auch PECL::APC (letzteres installiert man gaz simpel per pear install APC in der shell) cachen. Hierbei werden Scripte in Form von ausführbaren Opcodes im RAM gecached. Das bringt allerdings erst was, wenn Du viel Code und viele eingebundene Scripte hast.

Ich glaube, ich fange von vorne an, d.h. mache mal ein paar Tests mit dem anderen Server.
Das wird sowieso noch lustig genug, weil dann sicherlich noch an der DB gedreht werden muß.

Ach nochwas:
Ich sprach die ganze Zeit von einem gleichzeitigen Request. Wenn man z.B. 10 gleichzeitig abfeuert, geht die Latence natürlich hoch.
Dazu benutze ich einen zweiten Server. Bei habe ich über PEN verbunden.
Das Teil ist super, scheint keinerlei eigene Latence zu haben. Aber bei den meisten Linux-Distris ist noch ein anderes (etwas komplexeres) Paket dabei, das sich pound nennt.
Wenn ich es richtig verstanden habe, hat das zusätzlich noch einen Cache/Proxy, was der PEN nicht hat. Hat jemand damit Erfahrungen?

Um es kurz zu sagen:
Ich betreibe gerade etwas Forschung, wie ich mit möglichst wenig (Hardware-)Aufwand auf ca. 60 Anfragen pro Sekunde kommen kann...

Gruß
Reiner