Re: Re: Why mod_perl is good for PHP

[BUU]

It's fairly simple if you look at it. Mod_Perl and Mod_PHP have basically nothing in common. Basically mod_php is simply Apache::Registry, or possibly even less. It simply embeds the php interpreter in apache so it doesn't have to start it up for each script it calls. Mod_Perl on the other hand allows you to write complete modules for apache. It's commonly mentioned as simply away to speed up perl scripts, which is where this commmon misconception comes from, but thats nothing compared to the true power of mod_perl. It basically lets you rewrite any part of the apache request model you want, just like any of the other apache modules. Which is why real mod_perl hosting is more expensive, because you basically have to provide one apache server per person who wants mod perl, as anyone running mod_perl scripts has to have access to configuration file for the entire server, and theres no way to 'cordon off' various mod_perl scripts from each other.

Now what a hosting provider could do fairly easily is just set up Apache::Registry for each of it's clients in a certain directory,(and I think a few of them do this..) but that is nothing like mod_perl, it just a simple hack to speed up scripts.

[cees]

Now what a hosting provider could do fairly easily is just set up Apache::Registry for each of it's clients in a certain directory

If it was that easy then most ISP would be doing it. Imagine a simple registry script that did this:

package DBI;

sub connect {
  die "This program requires Microsoft Windows...";
}

1;

In perl you can write into any namespace that you like, and since mod_perl is persistant, then this new subroutine will hang around for as long as MaxRequestsPerChild determines, or until the server is restarted. So you can mess up anyone else that depends on DBI and is lucky enough to share a server with you.

mod_perl is too closely integrated into Apache to make this safe, and perl has no concept of permissions on namespaces (rightfully so).

However, all is not lost. mod_perl2 can solve this problem by using the perchild MPM where a fixed number of processes (that can run with different uids) create multiple threads to handle the requests. So each site that requires mod_perl will get their own playground that won't interfere with the other users.

The problem is that this version has not stabilized yet, so we need to wait a little bit longer before we can use these features. I believe that once this has stabilized you will see mod_perl becoming available at a lot more ISPs...

In the meantime, look at SpeedyCGI or FastCGI, which will do a lot to increase the speed of your perl scripts.

Cees

[mrd]

I know that you can do a lot more with mod_perl than with mod_php.

But if I only want to generate content in a fast, memory persistent way, I don't need to step in and take over the other phases of a server response. Apache::Registry would be just perfect for this, and I don't agree that it is "a simple hack". Just because it's so easy to use it, doesn't mean that you can't build "real" web-sites with it.

The fact we only have a choice between very cheap cgi scripts (with all their drawbacks) and a very expensive swiss-army knife is annoying.