is mod_perl better for CGI application?

[John]

This is more of a hosting question, I know.

We use Perl primarily to write our website. The site uses CGI.pm
extensively. So, every page begins my $x=param('x') etc and depending
on whether it is 'undef' will jump to some routine or other. Lots of forms.

Now, would we better off hosting on 'mod_perl' server, and what are the
key advantages?

Regards
John

 

[xhoster]

This is more of a hosting question, I know.

We use Perl primarily to write our website. The site uses CGI.pm
extensively. So, every page begins my $x=param('x') etc and depending
on whether it is 'undef' will jump to some routine or other. Lots of
forms.

Now, would we better off hosting on 'mod_perl' server, and what are the
key advantages?

The key advantage is the over-head speed and ability to cache database
handles and such. The disadvantage is that it is more finicky and easier
to screw up.

Are you having performance problems with your server keeping up with
requests, are these problems due to the start-up overhead of the CGI
scripts and the overhead of creating the database handles?

Xho

 

[Jamie]

This is more of a hosting question, I know.

We use Perl primarily to write our website. The site uses CGI.pm
extensively. So, every page begins my $x=param('x') etc and depending
on whether it is 'undef' will jump to some routine or other. Lots of forms.

Now, would we better off hosting on 'mod_perl' server, and what are the
key advantages?

mod_perl is really good if you need access to the internals of apache, you
can do amazing stuff with filters and configurations and so-forth.

It does however, add bloat to apache. It's also pretty easy to screw
up, a bit harder to develop for (for example, unless you tweak the settings,
you'll have to restart apache each time you change a file, since they are
loaded in memory.)

mod_perl is fast.

I stumbled across this (again) awhile ago:

http://www.fastcgi.com/

Basically, it'll turn your script(s) into daemons. Apache forwards
the connection to a daemon, the daemon handles the request.

Works with perl, it's fast and it'll let you do stuff like cache database
handles. Also enables you to do a fair amount of your work in plain CGI
and then "move over" to FastCGI as the time comes. I was blown away by
how fast it was (and how it simplified development model) You still
have the "restart problem" but you can do 99% of your work in CGI mode
and then flip over to FastCGI when the time comes.

At first, one would think that moving the process out of apache would slow
things down. Doesn't appear to be the case and it'll let you trim apache down
some-what, for serving static content.

I'd recommend checking into it.

For stuff that doesn't get used very often (control panel admin page, etc..)
plain CGI makes a lot of sense. Remember with mod_perl or FastCGI or servlets
or any of that stuff, the web application stays in memory, even when no one is
using it. By moving seldom used programs over to boring, flat CGI mode you can
free up more resources for the web applications that /DO/ get used a lot. (and
put those applications on FastCGI / mod_perl)

You'll get better overall response times this way.


Jamie

 

[Randal L. Schwartz]

Jamie> mod_perl is fast.

Jamie> I stumbled across this (again) awhile ago:

Jamie> http://www.fastcgi.com/

Keep in mind that mod_perl is far more than content-phase. mod_perl lets you
control and influence *every* phase (URL->resource, auth, MIME types,
logging). It's far more than a "fast replacement for CGI", which is what
fastcgi does.

 

[krakle]

mod_perl ...
It's also pretty easy to screw
up, a bit harder to develop for

In other words, mod_perl forces you to write valid Perl code and take
extra precautions. The only problem I ever had with mod_perl was some
variables sharing into another users sessions. And that was an easy
fix.

(for example, unless you tweak the settings,
you'll have to restart apache each time you change a file, since they are
loaded in memory.)

Actually, the server will check the modification time of the script
and if it has changed after that script has been loaded it will
recompile and store in memory. The only time you have to restart
apache is when you make modifications to a module. But it is good
practice to restart apache after modifying scripts to avoid pesky sub-
routine redefined warnings.

 

[Jamie]

In other words, mod_perl forces you to write valid Perl code and take
extra precautions. The only problem I ever had with mod_perl was some
variables sharing into another users sessions. And that was an easy
fix.

FastCGI has the same constraints. (the other problem is memory leaks)

Actually, the server will check the modification time of the script
and if it has changed after that script has been loaded it will
recompile and store in memory. The only time you have to restart
apache is when you make modifications to a module. But it is good
practice to restart apache after modifying scripts to avoid pesky sub-
routine redefined warnings.

FastCGI has those problems as well, except you can kill off the FastCGI
process instead of apache if you want.

It's just that with FastCGI, it's easier to develop the bulk of your code as a
plain cgi script and then port it. I find this easier.

It's also easy to move it back to regular CGI if it turns out you don't need
persistence. With mod_perl, you need to use Apache::Registry. (which kind of
kills the whole point) and you'll end up carrying perl code into each apache
instance. (may or may not be a problem)

As soon as you rely on anything "mod_perl specific", you can't easily go
back to regular CGI. You could wind up carrying around a web server
bloated down with code that goes unused most of the time.

Make no mistake, mod_perl is awesome. Particularly good when you
need access to the intricate details of apache. CGI can't compare
to that.

Jamie