bei Perl/CGI ist das hauptproblem, dass fuer jede anfrage perl gestartet werden, dann das script uebersetzt und ausgefuehrt werden muss. Fuer ein Gaestebuch mit 10 eintraegen pro Monat ist das eine gute wahl, aber wenn sehr viele anfragen kommen, ist das schon ein ganz schoener overhead.

Bei mod_perl gibt's viele verschiedene wege:

Apache::PerlRun(:?::Once)?: haelt perl im speicher (sagt ja mod_perl), compiliert aber das script inkl. Module bei jedem aufruf neu. das duerfte schon um einiges schneller als Perl/CGI sein (ich schaetze mal, so 3-8x, habe aber keine konkreten zahlen)

Apache::Registry: dies haelt auch das script im RAM, und zwar in eine Subroutine umcompiliert. Nur wenn sich die Datei auf der HDD aendert, wird neu compiliert. Laufzeitgewinn: geschaetzt 5-15x

Apache::Request: dies macht im Grunde dasselbe wie Apache::Registry, nur schreibt man selbst handler und keine kompletten programme. Dadurch kann man die funktionen, die apache eh schon hat, mitbenuetzen (z.B. Up-/Download von Dateien, Urls rewriten, authentication, cleanup, ...). Laufzeitgewinn: geschaetzt 10-30x

der laufzeitgewinn haengt natuerlich sehr von der aufgabe und wie man sie coded ab. sie entsprechen meinen Erfahrungswerten, wobei ich auch schon ziemliche ausreisser hatte. Nur mit Apache::PerlRun habe ich noch keine Erfahrung.

http://develop.perl-community.de/ basiert uebrigens auf Apache::Registry mit Ausnahme der Dateiup- und -downloads (Apache::Request), weil die da viel schneller zu schreiben waren.

Apache::DBI macht auch nur dann sinn, wenn man sich an der datenbank nur mit wenigen usercredentials anmeldet und diese verbindungen wieder benoetigt. wenn fuer jeden connect andere credentials benoetigt werden, ist Apache::DBI vermutlich langsamer als DBI pur.