Re: Re: Re: mod_perl and shared environments don't mix - do they?

[perrin]

in reply to Re: Re: mod_perl and shared environments don't mix - do they?
in thread mod_perl and shared environments don't mix - do they?

Limiting the amount of memory and CPU that mod_perl uses is also quite easy (using rlimits as in Apache::Resource).

I think you are misinformed about leaking memory. Most of the things people consider leaking memory under mod_perl are simply using memory as your program needs it to do more work. PHP will use memory too, if you load a big data structure from a file or database. Leaking requires you to code a circular structure or use a module with bad XS code. Running mod_perl by itself is quite stable.

PHP is not as fast as mod_perl. Numerous benchmarks have shown this, including the ones Yahoo did to decide on using PHP.

The subject of this thread was security, and why PHP is considered secure in a shared environment. The answers seem to be that it can be run as CGI (which of course is true of Perl as well) or that it can be run in a safe shared mode. The latter is an advantage over mod_perl for ISPs. At the moment, people looking for a cheap mod_perl ISP have to go for either a virtual server environment (where you get your own server with root access, but not a dedicated box) or SpeedyCGI.

[bean]

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...)

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.

[perrin]

It's true, Apache::Resource would allow malicious users to remove limits. It is meant to help people keep from shooting themselves in the foot, not to prevent intentional attacks. It might work better to set rlimits as root during apache startup.

it made sense to me since you can load C binaries in a Perl module

The extensions to PHP that allow things like database access are also written in C. As I understand it, writing custom PHP libraries that use C code is a very popular practice among high-volume sites.

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

Coding yourself vs. using a CPAN module is only faster if you can always write faster code than the people who write the modules. Given the high-quality of the most common Perl modules (DBI for example), this seems unlikely. There certainly are some large "kitchen-sink" CPAN modules out there, but anyone who is concerned about performance can easilly steer clear of them.

I don't think that mod_perl's API for accessing apache data is inherently more dangerous than the PHP equivalent. They both give you access to the same information about the request. What is more dangerous is that mod_perl doesn't provide a safe sandbox where code written by one user can't possibly affect code written by another. This is addressed in mod_perl 2, but it's not stable yet. Meanwhile, people looking for shared hosting with mod_perl still need to go with a virtual server or SpeedyCGI.

[bean]

The extensions to PHP that allow things like database access are also written in C. As I understand it, writing custom PHP libraries that use C code is a very popular practice among high-volume sites.

Yes, but the difference is that if a user has permission to run mod_perl as part of a shared server environment that user can load leaky C code - custom C modules for php would have to be compiled into the server by the administrator.

I don't think that mod_perl's API for accessing apache data is inherently more dangerous than the PHP equivalent. They both give you access to the same information about the request.

Mod_perl can modify apache internals - that's why it's so powerful. You can do anything with mod_perl that you could do with a C module (making it great for prototyping apache C modules). The only things PHP can modify are selected PHP settings and the server output.