Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

How to Fix CGI

by arkturuz (Curate)
on Nov 07, 2007 at 13:49 UTC ( #649483=perlnews: print w/replies, xml ) Need Help??

Seems like a really good idea: How to fix CGI

Replies are listed 'Best First'.
Re: How to Fix CGI
by tirwhan (Abbot) on Nov 07, 2007 at 15:11 UTC

    Hmm, I'm doubtful. AFAICS the assumption he makes is that simply having a persistent perl interpreter in memory, which loads scripts and modules at runtime, will save a lot of time and processing power. I don't think that assumption is correct. Try this in your shell:

    sh-3.1$ time perl -e '' real 0m0.005s user 0m0.000s sys 0m0.000s sh-3.1$ time perl -MCGI::Simple -e '' real 0m0.026s user 0m0.020s sys 0m0.000s

    Loading the perl interpreter, compiling and executing the noop takes 0.005 seconds, whereas doing the same and loading the CGI::Simple module takes more than five times as long (you can try this with CGI as well, but that's a little unkind ;-). His proposition would only manage to save a small part of the 0.005 seconds, namely the time it takes the OS to fork and start a new process and load the perl interpreter into memory. So I may have some flaw in my thinking here (in which case I'd be thankful if someone more knowledgeable than me could point it out), but I just don't see the point of his mod_perllite.

    Caveat: above is on Linux, things may be very much different on fork-challenged platforms ;-).

    All dogma is stupid.
      The key problems we want to work around are user and web host aversion to CGI and intense complexity and persistence of mod_perl. Imagine if this is all you needed to add to Apache before you could throw any file with a .pl extension into your web root and that's it, you're off and running Perl: LoadModule perlite_module modules/ AddType application/x-httpd-perlite .pl AddDirectoryIndex This we can sell shared hosting providers on. mod_perl we unfortunately cannot.
        Post above by moi, Aaron Stone, btw. The royal 'we' referring to 6A ;-)
        Apparently I didn't RTFM about how to comment with code...
        LoadModule perlite_module modules/ AddType application/x-httpd-perlite .pl AddDirectoryIndex
        My goal is to make this project 80% good at the 80% problem, and nothing more.
Re: How to Fix CGI
by perrin (Chancellor) on Nov 07, 2007 at 23:54 UTC
    I think that what he's missing here is that many ISPs run PHP via CGI, not via mod_php. They do this for security. In fact, PHP is not comparable in speed to mod_perl at all unless you use a code cache, which makes it stateful by keeping the compiled code in memory.

      ... which takes us back to the problems of using mod_perl in a shared hosting environment - any script can affect the environment of other users, and globals can persist from request to request. I don't know if similar problems exist in PHP.

      What would be an ideal starter environment is to be able to:

      • load Perl at startup
      • provide completely separate perl environments for different users
      • load all the required modules at startup
      • serve each request with a clean "just started" stack, so that previous requests have no impact.

      I know very little about the internals, but what about:

      • starting a single Perl interpreter ("root process")
      • forking a separate process for each customer / website - this acts as the "parent process" for each website
      • load required modules into this new "parent process"
      • for each request, fork a Perl interpreter from the "parent process"
      I may be barking up the wrong tree, and I don't know how heavy these forks are (whether they would be a real gain on using straight CGI), but it may be worth a shot.


        What you describe above is already possible with mod_perl. Just set MaxRequestsPerChild to 1, and each process will exit after a single request and cause another one to be forked.

        It's better than CGI, but it still sucks compared to really using mod_perl. It means you can't have persistent database connections, cached database statement handles or data, and similar performance tweaks that are only possible in a persistent environment.

      Code caching does not make mod_php stateful. It's equivalent to keeping .pmc files in memory. Nothing more.
        I admit to not being a PHP expert, but people who are have told me that when you use a code cache with PHP you hit similar scoping issues to the mod_perl ones. Otherwise, there would be no persistent database connections in PHP either.
Re: How to Fix CGI
by rootcho (Pilgrim) on Nov 15, 2007 at 18:57 UTC
    Is there some more recent comparison between mod_php/mod_perl/asp..fastcgi...etc..
    In the past there was some, but nowadays I don't see such comparisons.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlnews [id://649483]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (3)
As of 2017-08-18 23:48 GMT
Find Nodes?
    Voting Booth?
    Who is your favorite scientist and why?

    Results (310 votes). Check out past polls.