SPUG: Newbie mod_perl q: When modules are loaded

[Jonathan Gardner]

On Friday 07 May 2004 09:12 pm, Dan Sanderson wrote:
> Hi all -
>
> I'm getting started with mod_perl on a toy server I own.  (I have root
> and can modify Apache configuration, and can restart the web server.) 
> It's running Debian 3.0r2 stable, and I'm keeping it that way, which
> means I'm using Apache 1.3.26 and mod_perl 1.26.  I'm starting out with
> trying to use Apache::Registry to speed up regular Perl CGI scripts.
>
> I understand that mod_perl compiles and caches scripts and modules once
> on first load, and uses the cached versions on subsequent loads.

I'm going to be pedantic, but the end result will be less confusion, so it 
may be beneficial to all.

First off, mod_perl is an apache module that allows you to write perl code 
to plug into apache. Apache::Registry is a module that has a handler that 
can effectively "cache" CGI scripts.

You are going to have to grasp the mental concepts of how perl, Apache, and 
mod_perl work internally. This isn't too painful, but it will take some 
time. When you grasp these concepts, then you will be able to write your 
own apache modules and pretty much your own web server that behaves in the 
way you like. The investment is definitely worth it.

> Given that mod_perl doesn't reload modules with a high performance
> configuration, what's the best way to refresh the cache when new modules
> are deployed (presumably from a test instance to a production instance)?
>

The way I believe is best is to have several seperate instances of apache 
running, one or more for each developer. Assign a port (or group of ports) 
for each developer, and have them set up their servers on their ports. It 
would be best to have each apache (production, developer, testing, etc...) 
work from the exact same module and code base. In other words, compile 
apache once and use that for everything.

When you make a module change, restart the server by stopping then starting 
it. It is important that you do not rely on StatINC. I have seen too many 
problems appear when a module has been reloaded into a state that isn't the 
same as the state when it is first loaded. In fact, I would recommend to do 
the same while modifying CGI's. Work from a clean slate.

> Is there a better way to configure a development instance of a mod_perl
> website to reload modules when they change, than StatINC?

No, not that I know of.

> The docs tentatively suggest a couple of other options, but I get the
> impression there is no official recommendation.  Is that about right? 
>

Yes. There is no other way that is really good.

> Is mod_perl 2 better at this?
>

mod_perl 2 is not ready for production yet, so it is irrelevant. Besides, 
loading modules is a perl thing, not a mod_perl one, so I don't see how 
mod_perl 2 could fix this. Rather, it would be StatINC that would fix it, 
if anything.

-- 
Jonathan Gardner
jgardner at jonathangardner.net