Warum dieser Artikel?

Nachdem ich lange im Netz gesucht habe, bin ich nun der Meinung, dass über mod_perl/fastcgi nocht nicht genug geschrieben wurde. Meine Erkenntnisse stammen aus dem Lesen von ca. 50 Internetseiten und der Einrichtung eines Apache-Webservers, der sowohl mod_perl als auch fastcgi unterstützt. Einsteigern in das Thema möchte ich begreiflich machen, was es bringt damit zu arbeiten.
Meine Einschätzung der mod_perl/fastcgi-Techik: Meinen Recherchen zufolge waren beide schon im Jahr 1997 im Umlauf, aber noch sehr stark in der Entwicklung. Dabei zeichnete sich ab, dass mod_perl sehr schnell (innerhalb von zwei Jahren) sehr viele Entwickler für sich gewann. Die Community von mod_perl ist bis heute offenbar größer, als die von fastcgi. Man kann davon ausgehen, dass beide Techniken inzwischen recht ausgereift sind, weil an beiden schon lange herumgeforscht wird.
Randnotiz: Es gibt auch Implementierungen im Zusammenspiel mit PHP, mit denen ich mich aber aus Trotz nicht weiter beschäftigt habe, denn ich glaube immernoch nicht an eine wirklich gute Skalierbarkeit von PHP im Vergleich zu Perl (zu den Gründen werde ich auch nochmal einen Artikel schreiben).

mod_perl im Vergleich mit fastcgi

Beide techniken folgen dem gleichen Prinzip: Da es relativ lange dauert bis eine Instanz von Perl oder PHP geladen ist, wird der Interpreter einfach im Arbeitsspeicher gehalten.

mod_perl

ist ein in den bekannten Open-Source-HTTP-Server Apache eingebetteter Perlinterpreter. Er ist damit Teil der Apache-Instanz und wird nicht mehr als eigenständiger Prozess angezeigt/genuzt. Perlscripte werden dem laufenden Interpreter zum interpretieren gegeben. Dadurch sind minimale Modifikationen im Source ausreichend, um ein Perlprogramm mod_perl-tauglich zu machen.

Merkmale

  • Das Script muss bei jedem Aufruf erneut geladen werden, lediglich das Laden des Interpreters fällt weg. Gleichzeitig ein Vorteil, weil man nicht auf die validität von Variablen achten muss (siehe fastcgi)
  • Läft im Taint-Modus von Perl. Dadurch werden unter anderem keine use lib akzeptiert, die relative Pfade beinhalten. Testen kann man seine Scripte also vor einer mod_perl-installation durch den Aufruf an der Eingabeaufforderung mit perl -T meinscript.pl.
  • Läft nur auf dem Apache-Server.

fastcgi

folgt der Idee eine Instanz von Perl (also einen Prozess ständig offen zu halten. Der Webserver (fastcgi ist nicht an den Apache gebunden) ruft also eine Instanz des Programms bei seinem Start auf und das (Perl-)Programm ist dafür verantwortlich offen zu bleiben. Deshalb wird im Perlprogramm meistens eine while(1)-Schleife verwendet. Über die Schnittstelle von fastcgi ist es möglich abzufragen ob eine neue Anfrage von einem Client gekommen ist. So rattert das Programm also nicht die ganze Zeit durch seine Endlosschleife und lastet den Server zu 100% aus, sondern macht dann weiter, wenn eine Anfrage kommt. Bei der IPC kommt es seitens fastcgi und server zu einem gewissen overhead, daher: Die Kommunikationsgeschwindigkeit leidet ein wenig, weil perl eben nicht Teil der Serverinstanz ist und eine Kommunikation von Prozess zu Prozess realisiert werden muß, bevor überhaupt etwas passieren kann.

Merkmale

  • Da die Scripte in einer Endlosschleife laufen muss man penibel darauf achten, dass Speicher wieder freigegeben wird. Wichtig ist das besonders aus Sicherheitsrelevanten Gründen, weil es sonst beispielsweise passieren könnte, dass ein Gast einer Internetseite mit einmal als jemand anders eingeloggt ist, weil irgendeine Variable nicht anständig gepurged wurde.
  • FastCGI arbeitet mehr oder weniger unabhängig von Programmiersprachen, denn es gibt Portierungen nach C, Java, etc. und es ist außerdem nicht auf den Apache-Server beschränkt einsatzfähig.
  • Overhead bei der Inter-Process-Communication

Einrichtung auf dem Apache-Webserver

Um die eigene Konfiguration des Webservers zu testen können die beiden folgenden Scripte (s.u.) hilfreich sein. Die Dateinamenserweiterung ist frei anpassbar gemäß der Angaben, die man in der Serverkonfiguration vorgenommen hat. Ich habe für mod_perl-scripte die Erweiterung .mcgi gewählt, für fastcgi .fcgi. Zu beachten ist, dass die meisten Dokumentationen darauf zielen ein eigenes Verzeichnis für mod_perl bzw. fastcgi-dateien anzulegen. Dadurch kann auf dem Server nur dann ein mod_perl/fastcgi-script ausgeführt werden, wenn es sich im richtigen Ordner befindet. Oft wird ein Pfad vorgeschlagen wie http://localhost/~max/public_html/perl Dieses Verhalten findet sich aber auch im Umgang mit ganz normalen perl-scripten auf den Servern einiger bekannter Hoster wieder, z.B.: http://localhost/~max/public_html/cgi-bin. Ich persönlich bevorzuge die Art mit der Endung. Zwar könnte man ihr den Nachteil nachsagen, dass es nicht mehr Serverunabhängig läft oder schwerer auf andere portierbar wird, jedoch ist es ebensoviel Arbeit seine Scripte in auf einen cgi-bin-Ordner einzustellen, wenn den der Hoster vorgibt.

Konfigurationsdateien

mod_perl

Der grundsätzliche Aufbau ist ungefähr so und zwar nicht in der httpd.conf, sondern in der conf.d/perl.conf:
LoadModule perl_module modules/mod_perl.so
PerlSwitches -w
PerlSwitches -T
<Files ~ "\.mp_pl$|\.mcgi">
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
</Files>
<Location /perl-status>
SetHandler perl-script
PerlResponseHandler Apache2::Status
Order allow,deny
Deny from .example.com
Allow from all
</Location>

fastcgi

Ist einfacher einzurichten. Die folgenden drei Zeilen genügen:
LoadModule fastcgi_module modules/mod_fastcgi.so
FastCgiIpcDir /tmp/fcgi_ipc/
AddHandler fastcgi-script .fcgi

Testprogramme

mod_perl (test_fastcgi.mcgi)

#!/usr/bin/perl -t
use lib qq[/home/max/public_html/PlanB];
$i = 0;
print "Content-Type: Text/HTML\n\n";
print "Das ist ein Test";
print "Checking mod_perl...";
if (exists ($ENV{MOD_PERL}) or $ENV{GATEWAY_INTERFACE} =~ /^CGI-Perl/)
{ print "found! ".$i++; }
else
{ print "not found!"; }

fastcgi (test_fastcgi.fcgi)

#!/usr/bin/perl
use FCGI;
my $count = 0;
my $request = FCGI::Request();
while($request->Accept() >= 0)
{
print("Content-type: text/html\r\n\r\n", ++$count, "test");
print qq[is fastcgi: ].$request->IsFastCGI();
}

seLinux und fastcgi

Bei der Einrichtung von fastcgi ist mir aufgefallen, dass seLinux trotz vorhandener Richtlinie (in den Quellen verfügbar) nicht damit umgehen konnte. Den Grund habe ich noch nicht isoliert und zu Testzwecken erstmal auf permissive umgestellt. Damit klappt es.

Links/Quellen

Einige Quellen aus denen diese Informationen zum Teil stammen. Ich habe leider einige Tabs im Browser schon wieder geschlossen.
http://perl.apache.org/docs/general/perl_reference/perl_reference.html
http://perl.apache.org/docs/2.0/user/porting/porting.html
http://perl.apache.org/docs/1.0/guide/porting.html
http://perl.apache.org/docs/2.0/user/intro/start_fast.html
http://search.cpan.org/dist/mod_perl/lib/Apache/Registry.pm
http://modperlbook.org/html/13-1-Apache-Registry-PerlHandler-Versus-Custom-PerlHandler.html
http://www.heise.de/ix/artikel/2000/01/156/
http://www.mut.de/media_remote/katalog/bsp/[...]
http://www.perl.com/pub/a/2002/04/10/mod_perl.html

Autor

Ich bin nur ein Mensch und mache auch Fehler. Wenn hier jemandem etwas ins Auge sticht, was so nicht stimmt freue ich mich über Kommentare und darüber etwas zu lernen.
Weitere persönliche Hilfestellung bei der Einrichtung möchte ich aber unbezahlt nicht geben, denn das macht keinen Spaß, ist aufwendig und dröge.
zurück nach oben... Preview Admin-Bereich Impressum
Fliege