in reply to A Perl Daemon

I think you misunderstand what mod_perl is about, or have not spent a lot of time configuring it properly. The parts of Apache that lead to mod_perl being activated are small and efficient, so "getting rid of Apache" seems an odd goal.

Please make it clearer about why you've ruled out mod_perl. "forking" under mod_perl is no more expensive than forking under your proposed daemon. And you don't "load 3-4mb (sic) of modules every time" you fork under mod_perl. If you preload in the Apache parent process, nothing needs to be loaded per fork.

P.S. 3-4mb is 3 to 4 millibits. That's pretty small. Get 250 to 333 of those together, and you have an entire bit!

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Replies are listed 'Best First'.
Re^2: A Perl Daemon
by habit_forming (Monk) on Sep 06, 2005 at 20:07 UTC
    HA! 3-4 millibits. If all my problems were that small!

    While I am not a mod_perl expert I am well versed in it. I understand that forking will not be more expensive and I know that it does not load the modules everytime you fork, that is just silly. And yes getting rid of Apache is my goal here. I would like a Perl daemon. Something that loafs around with precompiled modules sitting in it just waiting to be used by a script that needs them. A kind of module pre-compiler. I want to be able to define which modules I am going to use very frequently have them precompiled, held in a pristine state and ready for use. The only thing close I could think of was mod_perl. Perhaps it was a bad example.

    --habit
[reply]
      There is PPerl and SpeedyCGI, but really they're about the same as using mod_perl. You haven't provided any reason why mod_perl wouldn't meet your needs here. Maybe if you gave a specific example of how you want to use this, it would become more clear.
[reply]
        Good point. The reason mod_perl does not meet my needs is because the code these scripts will be running does a lot of forking. The scripts do a lot of qx()'ing and system()'ing and such. And while I have tried to influence those writing these scripts not to do this, the problem persists. After all there are some good reasons to qx(). I tried mod_perl for quite some time and while much much faster I was getting strange behavior from Apache. Once I moved to CGI the strange behavior (i.e. defunct processes, unkillable children(hung on sockets), out of semaphore space errors, etc) cleared up completely. That is why I begrudgingly moved off of mod_perl.

        My base problem here is that I have a number of scripts that use a large complex of code. That complex of code is so large that this perl -MBigModuleTree -e 1 takes an average of 1.1 seconds. Yeah, it is pretty bad. So I am looking for a way to preload the BigModuleTree.pm thus reducing the time it takes to execute these scripts and also hopefully bringing the load down on the box.
        Hope this clears things up a bit.

        --habit
[reply]
[d/l]
      And yes getting rid of Apache is my goal here. I would like a Perl daemon. Something that loafs around with precompiled modules sitting in it just waiting to be used by a script that needs them. A kind of module pre-compiler.
      I must say that I have at best and extremely limited experience in this application area, but... I can't understand what your stated goals as in the quotation above could have to do with "getting rid of Apache". That is: once you have your hypothetical perld, do you want to use it to run a webserver written in Perl instead of Apache? If so, then there are some. But I doubt this is what you really want...
[reply]
        What was meant by "getting rid of Apache" was in reference to merlyn's response.

        The fact of the matter is that I have many different processes, that are not Apache, that come up on their own and use BigModuleTree.pm to do their work. I really like mod_perl and the way it handles things except for it's forking behavior. So a "standalone" mod_perl was the metaphor I was using to describe this perld idea.

        I still plan on using Apache to run the CGI's I have to run (with or without perld). I still plan on using mod_perl where ever I can (when not forking a bunch) but when not in Apache I would like to have something that could speed-up execution like mod_perl does. And since mod_perl accomplishes a lot of it's speed by being persistent... I thought, well why not a sort-of Apache divorced generalized mod_perl? That is where the idea started.

        --habit
[reply]

In Section Meditations