nicht angemeldet
hi Tom,
Das bedeutet also, dass das mod_perl die Verbindung aufbaut und hält? Wenn jetzt ein Request eintrifft, der durch das mod_perl zu bedienen ist, wird das Script doch aber erst zuende abgearbeitet, bevor das nächste in Angriff genommen wird, oder?
Unabhängig von einer DB-Verbindung (vereinfacht ausgedrückt): Bei mod_perl wird ein sog. ResponseHandler (Perl) zusammen mit dem Webserver gestartet und diesen Handler teilen sich mehrere Prozesse.
Somit ist der Perl-Interpreter selbst bereits am Laufen. Der ResponseHandler wiederum kann eine persistente DB-Verbindung bereitstellen, die dann auch geteilt werden kann.
Üblicherweise stellt der Webserver einen Kindprozess pro Request und der erzeugt dann eine Instanz des Perl- oder PHP-Codes.
PHP: Die Datei wird geparst, wenn <?php CODE ?> drin ist, wird der ausgeführt.
Perl: Wenn eine CGI-Schnittstelle konfiguriert ist, wird die Datei ausgeführt über den Perl-Interpreter. Dazu wird alles was an Code-Sourcen per use, require eingebunden ist und die Code-Sourcen vom Script kompiliert. Ein solcher Overhead ist der Killer bei großen Frameworks in denen viele Sourcen für jeden Request neu kompiliert werden müssen.
Linderung schafft der AutoLoader: Code-Sourcen werden erst kompiliert, wenn die entsprechenden Methoden/Funktionen aufgerufen werden, tatsächlich ists ja so, dass nicht ALLE Funktionen in JEDER Response gebraucht werden.
Neben der Möglichkeit AL einzusetzen, beschreite ich in meinem Framewwork einen völlig anderen Weg, der mit wenig Overhead einen reinen CGI-Betrieb ermöglicht, wobei jede Datei, die text/html ausliefert, Perl-Code enthalten kann ohne selbst eine ausführbare Datei zu sein. Näheres siehe Link, weiter unten findest Du auch einen PAP (Struktogramme mag ich nicht) ;)
Wobei: Mein FW habe ich auch unter mod_perl mit dem Template::Toolkit getestet, das geht ab wie ein geölter Blitz ;)
Hotti
Matthias Apsel