[quote=jan10001,06.11.2003, 20:08]Ich weiß nicht ob er bei einer internen Umleitung im Server auch ein path-info liefert. Das müßte man mal testen.[/quote]
doch, PATH_INFO wird beibehalten. hab ich grad ausgetestet...

strat, entweder habe ich deine antwort überlesen oder du meine frage ;)
ist cgi-bin ein scriptalias oder "nur" ein subdir von htdocs mit +ExecCGI?
hast du vielleicht irgendwas wildes wie scriptinterpretersource registry oder so an?
wundert mich ansonsten. kannst du nicht mal die httpd.conf rüberschicken oder hier anhängen oder sonstwo hochladen?

Quote

@Strat

wow, mit mod_perl laeuft es recht flott bei mir zuhause
cgi | mod_perl
-----------------------
0.38 | 0.06 | /overview/
0.33 | 0.03 | /board/19/
0.16 | 0.02 | anmeldeseite
Die Datenbasis ist identisch, lediglich mein PC zuhause ist etwas schneller, dafuer hat er windows drauf... und ein teil der html-seiten ist schon in xhtml

und dabei habe ich die templates noch gar nicht cachen lassen, weil das bei cgi kaum was bringt...

Deine dritte Lösung meinte ich eigentlich. :) Aber wenn es mit pl unter mod_perl flott läuft warum läßt du es dann nicht mal Probeweise auf dem Server laufen?

Quote

@pq

doch, PATH_INFO wird beibehalten. hab ich grad ausgetestet...

Hätte ich nicht gedacht, man lernt halt immer dazu.

wieso auch nicht? mit einem rewrite wird ja intern ein vollwertiger apache-request mit allem drum und dran gemacht, nur mit ein paar zusätzlichen infos.

aber wozu sollte man sowohl rewrite als auch path_info nutzen?

[quote=jan10001,06.11.2003, 23:32]Deine dritte Lösung meinte ich eigentlich. :) Aber wenn es mit pl unter mod_perl flott läuft warum läßt du es dann nicht mal Probeweise auf dem Server laufen?[/quote]
Ich moechte es, wenn es fertig ist, als mod_perl laufen lassen, und teste auch gelegentlich, ob da alles sauber laeuft. auf dem server ist mir cgi derzeit lieber, weil ich noch nicht ausschliessen kann, dass ich da noch memory leaks drinnen habe. Heute bis Sonntag koennte ich zwar eventuelle Probleme noch fixen, aber danach bin ich fuer einige Tage auswaerts auf einer Schulung, und danach etwa eine Woche bei meinen Eltern. Danach koennen wir es (hoffentlich) gerne mal ausprobieren, dann brauche ich aber moeglichst viel last, damit ich aussagekraeftigere daten bekommen kann.

Die Last kannst du bekommen, wenn fast alle Mitglieder versuchen zu selben Zeit das Board zu benutzen sollte ausreichend Last enstehen oder? Man müßte sie nur fragen und Bescheid geben wann es soweit ist.


Welche Vorteile bringt eigentlich mod_perl und wie benutze ich es? Zudem was ist der Unterschied (Vorteile / Nachteile) zwischen *.cgi und *.pl ?\n\n

<!--EDIT|jan10001|1068238954-->

zwischen .cgi und .pl gibt es so erstmal keinen unterschied, beide werden gleichermaßen interpretiert, wenn sie als cgi-scripts gekennzeichnet sind oder im cgi-bin liegen.

mod_perl hält a) deine scripts für die lebenszeit eines httpd-childs im speicher und sonst auch schon den gesamten perl-interpreter samt eingesetzter module. das bringt natürlich einfach einen großen performance-sprung, weil nicht jedes mal wieder ein neuer prozess für das cgi, der perlinterpreter in den speicher geladen, die syntax überprüft werden muss und das script anschließend compiliert werden muss (und wenn du module einsetzt, wird der aufwand dafür umso größer, was sogut wie jeder hier wohl intensiv tun, wozu das rad immer wieder neu erfinden). auf http://perl.apache.org findest du weitere informationen.

mod_perl bringt also geschwindigkeit (teilweise bis zu 20fach), kostet dafuer meistens mehr ram, weil die scripte ja schon "vorcompiliert" vorgehalten werden.
Weiters kommt man mit mod_perl viel besser an die Apache-APIs dran (nur mit C hat man da noch mehr moeglichkeiten). Man kann in jeden Abschnitt des Apache-Requestzyklus eingreifen, so z.B. seine eigene Userauthentifizierung machen (und ist nicht auf .htaccess angewiesen, ...)
Dann gibt es noch Apache::DBI, das recht erfolgreich versucht, Datenbankenverbindugen zu cachen (sodass der overhead des connects wegfaellt)
Und mod_perl-Module (fast alles, was mit Apache beginnt) sind meistens hervorragend geschwindigkeitsoptimiert
Man kann Module schon so vorladen (in der httpd.conf), dass sie zwischen den Apache-Threads geshared werden, und so doch wieder einiges an RAM sparen.
Die Endung tut zwar nichts zur sache, aber damit es fuer mich auf den ersten Blick klar ist, ob mod_perl oder Perl/CGI, verwende ich fuer CGI immer die Endung .cgi und mod_perl die Endung .pl
Und ein weiterer Vorteil ist, dass man wunderbare Memory-leaks schreiben kann, die oft sehr schwer zu finden sind...

[quote=Strat,08.11.2003, 00:29]Und ein weiterer Vorteil ist, dass man wunderbare Memory-leaks schreiben kann, die oft sehr schwer zu finden sind...[/quote]
dies liegt aber daran, dass man bei perl nie wirklich lernt, seine sachen wieder frei zugeben , was in vielen anderen sprachen sowieso ein MUSS ist...
=> Perl eigent sich in meinen Augen nicht dafür, eine Programmiersprache zu lernen <= aber das ist eine andere baustelle und sollte nicht in diesem thread diskutiert werden!

Red mal mit Joachim Ziegler drüber ;)

Und nein, Du mußt in anderen Sprachen nicht lernen, Speicher wieder frei zugeben: Denn es ist doch viel mehr in, ihn bis ans Ende der Uptime zu behalten. Jedenfalls tut das so manche erfolgreiche Software so... :cool: