On Thu, 25 Oct 2001, Scott R. Godin wrote: > > That fraction is about a third of what httpd would normally use. > > You're still talking about a hundred megs of memory when there are > > 120 httpd processes running at any one given point in time. > > Considering each process eats up about 6 megs of memory, and shares > > about a third to one half of that. (thats binary plus application > > together). The current stripped Apache binary is a little over two > > megs. Adding mod perl would increase to about four.
Read the mod_perl guide bit about front and back end Apache processes and explain it to him. This is worth doing for PHP too. http://perl.apache.org/guide/ > > Exactly. thus, the -entire- point about why PHP kicks the shit out of > > Perl. PHP behaves this way. Perl, on the other hand, does not. You > > PHP behaves this way ONLY because he's compiled it into apache, but he > won't admit that this is THE ONLY reason it has any advantage over > external perl processes. You are correct. PHP run as a CGI (which is possible) would probably be pretty slow too. Though it'd possibly be faster than Perl. > > are also missing one key "feature" regarding mod_perl. Perl scripts > > do not terminate after they finish. They remain in memory, compiled > > as a subroutine inside of the Apache:: registry. While this would > > normally be a respectible concept, it forces you to restart Apache > > -every time- you make a change to a CGI script. Change a variable > > name? Restart apache. Add a line of code? Restart apache. No thank > > you. > > O_o this is true? Restart the whole damned Apache, cuz I changed ONE > variable in a .cgi ? No, that's not true at all. Apache::Registry checks to see if the file has changed and will recompile it if necessary. > > As was mentioned in many email thus far, PHP -does- reload the script > > and parse/interprete/compile it -each- time it is accessed. The only > > diffence is that the interpreter itself is inside of the httpd > > binary. That is, of course, the entire point of a server side > > embedded scripting language. That would be a point _against_ PHP. You don't want it to go through the parsing and compiling every single time. Apparently that can be avoided if install a separate caching program. I think your sysadmin friend may have mentioned one, the Zend Cache, previously though I don't know if he said it was installed. > > Fuzz, if BU was just using Perl, and we were running UBB instead of > > Vbulletin, and none of the other hosted sites used PHP either, then > > sure. Why the hell not install mod_perl. But, you are in the > > minority here. Going from Perl to PHP is not difficult. As Pete > > mentioned, you can use this opportunity to grow as both a developer > > and an individual. I've done Perl for a long time. Many years ago, I > > was like you. I didn't want to use anything other than Perl. Now, > > I'm glad someone did the same thing to me. I think your sysadmin is mostly not wanting the additional maintenance hassle (understandable) but from a performance standpoint setting up a front/back Apache setup (with the back end doing _both_ PHP and mod_perl) would probably get better performance than just having a whole bunch of PHP'd frontend servers. As to whether its good for you as a developer. Maybe. If you're good with Perl I think you'd find PHP rather than limiting. Its kind of like Perl-lite. That's good for people just coming to web dev, as it lets you get off the ground quickly. For larger scale development, I'd always prefer Perl, as it has more features that make that easier (not that it can't also be done with PHP). But frankly, I don't think you're going to win your argument with this fellow. He's committed and he has the power. -dave /*================== www.urth.org We await the New Sun ==================*/
