FastCGI Nutzen in der Shell?

[alex]

huhu,

kann mir fastcgi irgendwelche vorteile bringen, wenn ich meine skripte lediglich per shell aufrufe?

wenn es mir nichts nutzt, gibt es denn eine andere möglichkeit den interpreter zu "cachen"?

alex

[asdf]

Hey,

kann mir fastcgi irgendwelche vorteile bringen, wenn ich meine skripte lediglich per shell aufrufe?

hmm gute frage, steht wahrscheinlich im manual. (es ginge z.b. mit wget http://localhost/skript.pl, da ja webserver und eingerichtetes fcgi)

ansonsten "man perlcc" (-O oder auch -B) oder man könnte auch eine ramdisk verwenden, ich denke dass letzeres nur marginale vorteile bringen wird.

gruss

[Siechfred]

kann mir fastcgi irgendwelche vorteile bringen, wenn ich meine skripte lediglich per shell aufrufe?

Ich glaube nicht, da FastCGI auf dem Server-Prinzip aufsetzt, während Shellscripte direkt durch den Perl-Interpreter gejagt werden.

wenn es mir nichts nutzt, gibt es denn eine andere möglichkeit den interpreter zu "cachen"?

Schau dir mal Perl-Cache an, ich habe es zwar noch nicht genutzt, aber evtl. hilft es dir weiter (siehe auch Perl-Cache auf SourceForge).

Siechfred

[alex]

danke für den tipp, aber ich fürchte das nützt mir nicht viel.

ich bin mir nicht sicher, worin der vorteil von den modulen liegt. ich nutze mysql um daten zu speichern und meine prozesse greifen auch regelmäßig darauf zu. das kann man in dem sinne auch als cache bezeichnen, oder? wozu also noch ein modul laden, wenn man sich nicht 100% darauf verlassen kann und mysql eh braucht. sicher dauerts evtl n bissl länger um mit der db zu connecten etc, aber mir gehts eher um speicheroptimierung als performance...

am meisten gewinn würde ich wohl machen, wenn ich für jeden prozess nicht immer perl starten müsste, kann man perl nicht irgendwie als daemon laufen lassen (ich meine nicht, dass ich nen skript als daemon laufen lasse, welches die neuen prozesse forkt)

alex

kann mir fastcgi irgendwelche vorteile bringen, wenn ich meine skripte lediglich per shell aufrufe?

Ich glaube nicht, da FastCGI auf dem Server-Prinzip aufsetzt, während Shellscripte direkt durch den Perl-Interpreter gejagt werden.

wenn es mir nichts nutzt, gibt es denn eine andere möglichkeit den interpreter zu "cachen"?

Schau dir mal Perl-Cache an, ich habe es zwar noch nicht genutzt, aber evtl. hilft es dir weiter (siehe auch Perl-Cache auf SourceForge).

Siechfred

[Struppi]

am meisten gewinn würde ich wohl machen, wenn ich für jeden prozess nicht immer perl starten müsste, kann man perl nicht irgendwie als daemon laufen lassen (ich meine nicht, dass ich nen skript als daemon laufen lasse, welches die neuen prozesse forkt)

Wieviel Gewinn erwartest du denn da?

Hast du mal versucht die Zeit zu messen, die der Perl Interpreter braucht um zu starten? auf einen normalen Rechner dürfte dir das kaum gelingen, da es sich um Bruchteile ener Sekunde handelt.

Speicherprobleme unter Perl treten in der Regel nur auf, wenn du massiv merhere MB an Daten im Speicher hälst, wenn du nicht musst, dann solltest du sowas vermeiden.

Struppi.

[alex]

huhu,

es geht ja nicht um die zeit, die perl benötigt, das ist schnell genug, es geht um den speicher, den jeder prozess frißt.

momentan sind es ca 17mb pro prozess und das scheint mir zu viel.
ich hab mehrere scripte umgeschrieben und module daraus gebastelt, das ganze etwas objektorientierter gestaltet. aber ein richtiger vorteil (bis auf die wartbarkeit) ist noch nicht rausgesprungen.

wahrscheinlich muß man in sachen speichereffizienz an anderen schrauben drehen als am code, aber ich schau gerne nochmal drüber.

danke trotzdem
alex

am meisten gewinn würde ich wohl machen, wenn ich für jeden prozess nicht immer perl starten müsste, kann man perl nicht irgendwie als daemon laufen lassen (ich meine nicht, dass ich nen skript als daemon laufen lasse, welches die neuen prozesse forkt)

Wieviel Gewinn erwartest du denn da?

Hast du mal versucht die Zeit zu messen, die der Perl Interpreter braucht um zu starten? auf einen normalen Rechner dürfte dir das kaum gelingen, da es sich um Bruchteile ener Sekunde handelt.

Speicherprobleme unter Perl treten in der Regel nur auf, wenn du massiv merhere MB an Daten im Speicher hälst, wenn du nicht musst, dann solltest du sowas vermeiden.

Struppi.

[Struppi]

momentan sind es ca 17mb pro prozess und das scheint mir zu viel.

z.b. Dateien komplett einlesen ist ein gern gemachter Speicherfresser.

ich hab mehrere scripte umgeschrieben und module daraus gebastelt, das ganze etwas objektorientierter gestaltet. aber ein richtiger vorteil (bis auf die wartbarkeit) ist noch nicht rausgesprungen.

Das ist klar, OO ist ist i.d.R. langsamer oder braucht mehr Speicher.

wahrscheinlich muß man in sachen speichereffizienz an anderen schrauben drehen als am code, aber ich schau gerne nochmal drüber.

wird wohl deine einzige Möglichkeit sein, da wir ja keine Infos haben.

Struppi.