Ligthttp, fastCGI und C++
gepostet vor 17 Jahre, 2 Monate von None
Wie sieht es mit einer Zusammensetzung des ligthttp-Server, Verwendung von fastCGI und C++ aus. Ist dies eine performante und sichere Lösung?
gepostet vor 17 Jahre, 2 Monate von Agmemon
Wie ich hier ja schon öfter geschrieben habe, ist lighttpd in Verbindung mit FastCGI wirklich ein Turbo. Gerne verweise ich dabei auch nochmal auf meine Tests, die ich im Studium gemacht habe:
www.kueken.net/archives/2006/06/#000010%23more
In den letzten Wochen hatte ich wieder zwei Fälle, in denen sich lighttpd bewährt hat:
1. Für unsere internen Tests haben wir uns einen neuen VServer zugelegt und unsere Anwendungsstruktur umgestellt. Als WebServer was ein Apache mit mod_proxy vorgesehen, der die Anfragen von Aussen auf ein Mongrel-Cluster verteilen sollte. Allerdings sorgte Apache 2.x in Verbindung mit MySQL 5.0 mit InnoDB dafür, dass wir eine Auslastung von 80% der zugesicherten Ressourcen hatten, ohne dass der Mongrel Cluster am Laufen war. Daher flog der Apache wieder runter und wurde mit einem Lighttpd mit mod_proxy ersetzt. Das System liegt jetzt bei 60% Auslastung inkl. dem Mongrel Cluster mit 5 laufenden Mongrel Instanzen.
2. Die Tage habe ich einem Studienkollegen, bei einer Kleinigkeit für seine Diplomarbeit, geholfen. Es würde zu weit führen, die Thematik zu erläutern. Zum Verständnis: es ging um Angriffsszenarien auf einen Standard zur Übermittlung von Geschäftsdokumenten über HTTP. Auch hier haben wir einen Test gemacht, wie sich Lighttpd inkl. FastCGI verhält. Und auch in diesem Szenario haben sich die Vorteile ganz klar gezeigt. Die FastCGI Skripte waren dabei, im Gegensatz zu meinen Tests, diesmal in C/C++ geschrieben.
Der einzige Nachteil, den ich bei Lighttpd im Moment sehe, ist die Entwicklungsgeschwindigkeit. Während der Apache eine gewisse Grundstabilität hat, geht die Entwicklung am Lighttpd rasend voran. Und damit ändert sich auch ständig etwas. Daher wird der Lighttpd in Fachkreisen noch nicht für geschäftskritische Anwendungen empfohlen. Ich habe aber noch keine schlechten Erfahrungen damit gemacht, ausser das hier und da mal ein FastCGI Prozess irgendwann die Arbeit einstellt, was sich aber mit einem kleinen CRON-Job leicht beheben lässt und die Anwendung nicht wirklich beeinträchtigt.
www.kueken.net/archives/2006/06/#000010%23more
In den letzten Wochen hatte ich wieder zwei Fälle, in denen sich lighttpd bewährt hat:
1. Für unsere internen Tests haben wir uns einen neuen VServer zugelegt und unsere Anwendungsstruktur umgestellt. Als WebServer was ein Apache mit mod_proxy vorgesehen, der die Anfragen von Aussen auf ein Mongrel-Cluster verteilen sollte. Allerdings sorgte Apache 2.x in Verbindung mit MySQL 5.0 mit InnoDB dafür, dass wir eine Auslastung von 80% der zugesicherten Ressourcen hatten, ohne dass der Mongrel Cluster am Laufen war. Daher flog der Apache wieder runter und wurde mit einem Lighttpd mit mod_proxy ersetzt. Das System liegt jetzt bei 60% Auslastung inkl. dem Mongrel Cluster mit 5 laufenden Mongrel Instanzen.
2. Die Tage habe ich einem Studienkollegen, bei einer Kleinigkeit für seine Diplomarbeit, geholfen. Es würde zu weit führen, die Thematik zu erläutern. Zum Verständnis: es ging um Angriffsszenarien auf einen Standard zur Übermittlung von Geschäftsdokumenten über HTTP. Auch hier haben wir einen Test gemacht, wie sich Lighttpd inkl. FastCGI verhält. Und auch in diesem Szenario haben sich die Vorteile ganz klar gezeigt. Die FastCGI Skripte waren dabei, im Gegensatz zu meinen Tests, diesmal in C/C++ geschrieben.
Der einzige Nachteil, den ich bei Lighttpd im Moment sehe, ist die Entwicklungsgeschwindigkeit. Während der Apache eine gewisse Grundstabilität hat, geht die Entwicklung am Lighttpd rasend voran. Und damit ändert sich auch ständig etwas. Daher wird der Lighttpd in Fachkreisen noch nicht für geschäftskritische Anwendungen empfohlen. Ich habe aber noch keine schlechten Erfahrungen damit gemacht, ausser das hier und da mal ein FastCGI Prozess irgendwann die Arbeit einstellt, was sich aber mit einem kleinen CRON-Job leicht beheben lässt und die Anwendung nicht wirklich beeinträchtigt.
gepostet vor 17 Jahre, 2 Monate von Klaus
Zufällig beschäftige ich mich gerade damit.
Allerdings bin ich nicht sehr weit mit meiner Recherche gekommen, in wieweit die Implementation genau aussieht.
Der Vorteil liegt klar auf der Hand, denn dein FCGI Programm läuft ununterbrochen und hat libs und Variablen bereits geladen. Die Verbindungen werden in einer Schleife bearbeitet und genau da fehlt es mir an Detailinformationen. Hast du vielleicht einige spezifische Beispiele?
Allerdings bin ich nicht sehr weit mit meiner Recherche gekommen, in wieweit die Implementation genau aussieht.
Der Vorteil liegt klar auf der Hand, denn dein FCGI Programm läuft ununterbrochen und hat libs und Variablen bereits geladen. Die Verbindungen werden in einer Schleife bearbeitet und genau da fehlt es mir an Detailinformationen. Hast du vielleicht einige spezifische Beispiele?
gepostet vor 17 Jahre, 2 Monate von Agmemon
Also der Grundaufbau ist in allen Sprachen ziemlich ähnlich:
Start der Schleife
Abarbeitung des Requests
Ende der Schleife
Aufräumen der Initialisierung
Damit sind kaum Änderungen am Code notwendig. Man zieht die Initialisierung aus dem vorhandenem Code raus und umgibt den eigentlichen Code mit der FastCGI Schleife. Wie man dass dann genau macht und konzipiert hängt aber von der verwendeten Sprache ab.
Initialisierung
Start der Schleife
Abarbeitung des Requests
Ende der Schleife
Aufräumen der Initialisierung
Damit sind kaum Änderungen am Code notwendig. Man zieht die Initialisierung aus dem vorhandenem Code raus und umgibt den eigentlichen Code mit der FastCGI Schleife. Wie man dass dann genau macht und konzipiert hängt aber von der verwendeten Sprache ab.
gepostet vor 17 Jahre, 2 Monate von Klaus
Ich nutze wie der OP C++ und das Veispielprogramm läuft ja auch:
{
/* Response loop */
int count = 0;
while (FCGI_Accept() >= 0)
{
printf("Content-type: text/html\r\n"
"\r\n"
"FastCGI Hello!"
"FastCGI Hello!"
"Request number %d running on host %s\n",
++count, getenv("SERVER_NAME"));
}
return 0;
}
Allerdings läuft die Ausgabe in die Konsole und ich finde nichts dazu, wie ich lighty konfigurieren muss, damit es die Anfragen an mein Programm durchreicht.
int main(void)
{
/* Response loop */
int count = 0;
while (FCGI_Accept() >= 0)
{
printf("Content-type: text/html\r\n"
"\r\n"
"FastCGI Hello!"
"FastCGI Hello!"
"Request number %d running on host %s\n",
++count, getenv("SERVER_NAME"));
}
return 0;
}
Allerdings läuft die Ausgabe in die Konsole und ich finde nichts dazu, wie ich lighty konfigurieren muss, damit es die Anfragen an mein Programm durchreicht.
gepostet vor 17 Jahre, 2 Monate von Agmemon
Hast Du Dein Programm in der FastCGI Direktive in der Lighty Konfiguration eingegeben?
gepostet vor 17 Jahre, 2 Monate von Klaus
OK hab es doch hinbekommen, obwohl es ne schwere Geburt war.
Folgenden Code habe ich in der lighttpd-Config eingetragen
fastcgi.server = ( ".fcgi" =>
(( "socket" => "/tmp/fcgi.socket",
"bin-path" => "/tmp/testProg",
"min-procs" => 1,
"max-procs" => 1,
"max-load-per-proc" => 4,
))
)
Wobei ich noch nicht weiß, was es mit diesem Socket auf sich hat. Mag mich jemand aufklären?
Um dann localhost/bla.fcgi aufzurufen musste ich noch eine leere Datei bla.fcgi anlegen, um bei meinem Backend zu landen.
Aber das Ergebnis scheint gut zu sein. 14ms Reaktionszeit für das kleine dynamische "Hello World". Mal schauen wie die Performance aussieht wenn ich noch GET/POST verarbeiten muss.
Folgenden Code habe ich in der lighttpd-Config eingetragen
fastcgi.server = ( ".fcgi" =>
(( "socket" => "/tmp/fcgi.socket",
"bin-path" => "/tmp/testProg",
"min-procs" => 1,
"max-procs" => 1,
"max-load-per-proc" => 4,
))
)
Wobei ich noch nicht weiß, was es mit diesem Socket auf sich hat. Mag mich jemand aufklären?
Um dann localhost/bla.fcgi aufzurufen musste ich noch eine leere Datei bla.fcgi anlegen, um bei meinem Backend zu landen.
Aber das Ergebnis scheint gut zu sein. 14ms Reaktionszeit für das kleine dynamische "Hello World". Mal schauen wie die Performance aussieht wenn ich noch GET/POST verarbeiten muss.
gepostet vor 17 Jahre, 2 Monate von None
Hat jemand ein Tutorial für diese Kombination für Windows und Linux? Wenn möglich auf Deutsch kann aber auch auf Englisch sein.
gepostet vor 17 Jahre, 2 Monate von Agmemon
Also ein vollständiges Tutorial fällt mir jetzt nicht ein, aber vielleicht helfen Dir diese einzelnen Tutorials:
In diesem Tutorial geht es darum, den gesamten Rails-Stack unter OS X zu installieren, inklusive Lighttpd und FastCGI. Das ganze lässt sich aber fast 1 zu 1 auf Linux übertragen. Die Rails Sachen dann halt einfach weglassen:
hivelogic.com/narrative/articles/ruby_rails_lighttpd_mysql_tiger?status=301
Hier findest Du alle wichtigen Dokumente und Anleitungen zu FastCGI:
www.fastcgi.com/devkit/doc/overview.html
Und hier die Dokumentation zur Einrichtung von FastCGI im Lighttpd, leider mittlerweile sehr PHP lastig:
trac.lighttpd.net/trac/wiki/Docs%3AModFastCGI
In diesem Tutorial geht es darum, den gesamten Rails-Stack unter OS X zu installieren, inklusive Lighttpd und FastCGI. Das ganze lässt sich aber fast 1 zu 1 auf Linux übertragen. Die Rails Sachen dann halt einfach weglassen:
hivelogic.com/narrative/articles/ruby_rails_lighttpd_mysql_tiger?status=301
Hier findest Du alle wichtigen Dokumente und Anleitungen zu FastCGI:
www.fastcgi.com/devkit/doc/overview.html
Und hier die Dokumentation zur Einrichtung von FastCGI im Lighttpd, leider mittlerweile sehr PHP lastig:
trac.lighttpd.net/trac/wiki/Docs%3AModFastCGI
gepostet vor 17 Jahre, 2 Monate von mifritscher
Klaus, meine Vermutung(!) ist dass der fastcgi-server dann auf diesem Socket auf Befehle wartet. In Windows gibt's halt die named pipes
Aber auch die IP-Ports sind sehr ähnlich
Aber auch die IP-Ports sind sehr ähnlich
gepostet vor 17 Jahre, 2 Monate von Agmemon
Original von mifritscherIn Windows gibt's halt die named pipes
Nicht nur unter Windows.
Die Sock-Dateien sind der Einhängpunkt der Full-Duplex Pipes (Named Pipes sind nämlich nur HalfDuplex) im Dateisystem, über die mit dem FastCGI Prozess kommuniziert wird. Liegen die FastCGI Prozesse auf einem anderem Rechner, wird normale Socket-Kommunikation verwendet.
gepostet vor 17 Jahre, 2 Monate von force4
Wir benutzen auch lighttpd mit FastCGI, und die Kiste rennt wie sonst was.
Ich habe noch nie wirklich mit Apache(2) gearbeitet, weil mich der Umfang meist abgeschreckt hat.
Aber beim lighty ist es absolut einfach, eigene Configurations zu erstellen, mod-rewrite anzupassen, Subdomains 1) anzulesen etc.
Ich kann ihn nur empfehlen
1): Es gibt ein Modul, mit dessen Hilfe man jediglich ein neues Verzeichnis zu erstellen braucht, um eine neue Subdomain anzulegen.
Ich habe noch nie wirklich mit Apache(2) gearbeitet, weil mich der Umfang meist abgeschreckt hat.
Aber beim lighty ist es absolut einfach, eigene Configurations zu erstellen, mod-rewrite anzupassen, Subdomains 1) anzulesen etc.
Ich kann ihn nur empfehlen
1): Es gibt ein Modul, mit dessen Hilfe man jediglich ein neues Verzeichnis zu erstellen braucht, um eine neue Subdomain anzulegen.