I thought the subject of the thread was why mod_perl doesn't work in a shared environment (maybe I should read more than the headlines...)
in reply to Re: Re: Re: mod_perl and shared environments don't mix - do they?
in thread mod_perl and shared environments don't mix - do they?
Anyways, if you use a perl module to limit the memory and CPU usage of a mod_perl script, it would seem that in a shared environment you're letting the fox guard the henhouse - unless Apache::Resource prevents the children from accessing the same functionality.
I may well be wrong about mod_perl leaking memory - that tidbit is based on hearsay from 4-5 years ago. However, it made sense to me since you can load C binaries in a Perl module. I guess you could run a binary from php using a system call, but the sysadmin can disable functions and the changing of environment variables from the php.ini, making this easy to stop.
As far as speed goes, mod_perl may well be faster than the equivalent php code, but that wasn't the point - the point was that it's more likely that the php code will be leaner, since the temptation to load 20 modules isn't there (there aren't 20 modules worth loading). So the php code tends to be written precisely to the purpose at hand, and may easily be half as complex, giving it a speed advantage.
The long and the short of it is, system administrators don't want you to have access to apache internals - it makes them nervous.