Hi.

Wir haben in unserem Projekt einen eigene Servereinheit (Sentinel), die gleichzeitig HTTP, SMTP, POP3 Server ist, auch Process überwacht und ggf. neu startet, etcpp.

Dieser hat auch ein CGI Schnittstelle und unterstützt auch Perl.

Jetzt wollen wir, sowas wie mod_perl nachbauen - natürlich nur in einer Lite Version.

1.) Perl script wird von Sentinel gestartet, macht einen listen-socket auf und wartet auf eine connection. Irgendwann bekommt es dann über ein vorher vereinbartes Protokol vom Sentinel Daten zugeschickt, in der Form

welches ein neues environment darstellt, welches ich mir dann in meine bestehendes einpflege...
bevor dies geschieht, hat Sentinel schon mein STDIN geschlossen, es wieder geöffnet und die POST Daten vom Request über geben...
wenn ich jetzt CGI->new mache, habe ich dann die neuen Daten in meinem CGI object oder puffert die CGI.pm irgendwie anders... z.B. schon bei use CGI oder so?

2.) Wie hat Apache das denn gelöst, wenn zwei requests gleichzeitig ankommen? Werden die scripte geforkt? Oder wie?


Dankbar für Hinweise.

Gruß
-sak

ad 2. apache1.3 forkt beim start ein paar prozesse weg (unter windows (ok, da ist apache1.3 eh nur fuer entwicklungszwecke sinnvoll): da dort threads verwendet werden und perl bis 5.6 absolut nicht und ab 5.8 nur teilweise threadsafe ist, ist da mod_perl auf einen prozess beschraenkt), an die dann die connections weitergegeben werden. diese prozesse nehmen je nach konfiguration eine bestimmte anzahl von connections an und bearbeiten diese, bevor sie neu gestartet werden (bzw. beendet und der vater forkt einen weiteren weg). man kann es aber auch so konfigurieren, dass die prozesse bei einer bestimmten speichergroesse neu gestartet werden, oder was auch immer
apache2 bietet da mehr optionen, so z.B. auch threads. deshalb laeuft apache2+mod_perl nur mit perl5.8 sinnvoll. aber fuer genaueres siehe am besten http://httpd.apache.org (bin da nicht mehr up-to-date)

mod_perl-nachbauen wird schwierig, weil du da den perl-interpreter in den server einbauen musst. als alternative koennte vielleicht POE dienen, weil man mit dem auch einfach einen webserver erstellen kann. HTTP::Daemon kann man leider noch nicht vernuenftig forken, wenn ich mich recht erinnere... vielleicht waere es am sinnvollsten, mal zu schauen, wie CGI::Fast bzw. FastCGI arbeiten...\n\n

<!--EDIT|Strat|1081205332-->

wieso... wir starten das perlscript ganz normal mit perl.exe und das perl script module macht dann nen listen socket auf und wartet bis der Sentinel bei sich meldet...
wenn esr sich gemeldet hat, dann arbeitet es ganz normal (mit neuem ENV und neuem STDIN) und kehrt wieder zum socket-accept zurück und das spiel beginnt von vorne...
da brauch man dann keinen perl-interpreter in den Server einbauen...

Frage ist: wird dies allein einen performance gewinn erzielen?

@esskar: das hat aber dann nichts mit mod_perl zu tun.
mod_perl ist noch viel mehr (und das willst du auch gar nicht alles nachbauen).
FastCGI ist z.B. eine alternative zu mod_perl, und auch davon wirst du nur
eine lite-version nachbauen wollen.
verstehe ich das richtig, dass du z.Zt. ein einziges perl-script am laufen
hast, dem du requests weiterschickst? dann wird es je nach traffic wahrscheinlich
sogar weniger performant sein, da ja immer nur ein script alle requests
nacheinander abarbeiten muss.
schau dir mal, wie schon vorgeschlagen, POE an, ich hab da auch mal
kurz mit rumexperimentiert, habe aber dann doch apache als lösung
genommen (ich wollte einen proxy-server bauen).