You need to read the manual. Just installing mod_perl on your web server isn't enough to have your scripts be cached (and accelerated) by it.

You have to have some way of telling your webserver that you want a script to be cached by mod_perl. This is set in your httpd.conf file (assuming apache), either by mapping files in a certain location, or files with a certain extension, to be handled by a mod_perl handler. (Usually Apache::Registry, unless you write your own. I don't, usually.)

8.8 requests/sec doesn't sound like your CGIs are being handled by mod_perl at all. Some very expensive scripts, processor-wise, I've written that use mod_perl run in the 140 to 160 requests/sec range, and 10-11 requests/sec not under mod_perl.

There are other issues around mod_perl usage. Basically, you need clean code, lexically scoped and without globals. Read the docs I pointed you at above and you'll learn quite a bit.

Stick with it! mod_perl is excellent! Here's a node I started a little while ago when I was just learning mod_perl. You can learn a lot in a few months!

Just installing ( assuming it was done correctly ) mod_perl may or may not increase the speed of your script.

As I undestand it, mod_perl caches scripts and library files, and library files are where you get the most benefit from

Consider this example: Suppose all of your scripts in your server uses CGI.pm. You *know* that this is a rather big module. I'm sure it's got tons of enhancements, but I'm sure it takes longer than a trivial module.

But with mod_perl, you get the benefit of having this CGI.pm compiled and loaded in memory in each httpd child. So you save the time to recompile and load the module for every single script that you run. That's cool.

Now suppose each script "use"s 4-5 modules of about the same size as CGI.pm. That's A LOT.

Also, in my view the biggest difference ( that I could feel ) comes in when you have some DBI connection that you need to open within your script. Using mod_perl with Apache::DBI, you get to keep your DBI connections open ( for a while anyway )! Now, *that* you can feel

So I think it really depends on what you are doing in your script. If you just have short scripts, which don't load many modules and don't really require costly things like opening up a DBI connection, then my guess is that you are not going to see much difference

lestrrat you got it partially right, assuming you're only using the Apache::PerlRun handler.

First off, mod_perl doesn't cache "library files" unless you tell it to in httpd.conf.

If you haven't set a handler for your scripts you won't be getting any benefits. mod_perl only caches "library files" for other scripts handled by mod_perl. e.g. if you pre-load CGI.pm in your httpd binary with mod_perl, you'll be preloading it for your mod_perl scripts only. Again, if you don't set up a handler (in httpd.conf) for scripts to be cached by mod_perl, you won't see any benefits.

There's a couple of major handlers you'll use, (assuming you don't write your own), Apache::PerlRun and Apache::Registry.

Apache::PerlRun caches modules for other scripts handled by Apache::PerlRun (and probably Apache::Registry). The scripts handled by PerlRun still have to load and compile themselves, but not the modules. You'll see an increase in scripts that use modules that are handled under PerlRun

Apache::Registry caches the script itself and the modules. This is where you get the huge speed increases, whether or not you use modules. Each call to the script comes directly from the httpd binary, bypassing the load and compile phase.

Put another way, straight mod_cgi scripts still load in modules, compile, and then exit usually, offering you none of the benefits of mod_perl. If you set these non-persistent scripts to be handled by the Apache::PerlRun handler, then you will see a small speed increase because the module caching will happen, though the script itself will be compiled and run on each execute.

On the simple script without many modules thing, you won't see many benefits under Apache::PerlRun because the scripts themselves aren't being cached. If you have scripts that use many modules and run them under Apache::PerlRun, you will see an increase in speed.

However, pretty much any script run under Apache::Registry will have a huge speed increase, whether or not it uses modules. This is because each instance of the script doesn't have to be reloaded and compiled, it's resident in the httpd binary.

The Bottom Line
• You will see a huge increase in speed for pretty much any script under Apache::Registry (the persistent handler),
• You won't see an increase for scripts that don't use modules under Apache::PerlRun (the non-persistent, but module caching handler),
• You will see an increase for scripts that DO use modules under Apache::PerlRun, but no where near what you'd see under Apache::Registry.

Hope this clears things up!

Ah, I haven't really used Apache::PerlRun, so I wasn't aware of that difference. I exclusively use Apache::Registry, and thought that *that* was the heart of mod_perl

But I still do would like to point out that if the script itself is relatively small, I personally didn't see much of a difference -- that is, not enough to make me go ga-ga over mod_perl. Maybe it was just that my particular configuration was that way, but since this original poster seemed unsure if mod_perl was doing its magic, I wanted to point out that the perceived difference may not be that big, if the initial compilation overhead wasn't as big.

Does that make sense?

Anyhow, I learned the difference between Apache::PerlRun and Apache::Registry today. that's cool. Thanks