On 2/1/07, Uri Guttman <[EMAIL PROTECTED]> wrote: > >>>>> "js" == john saylor <[EMAIL PROTECTED]> writes: [...] > js> wtf! it sure ain't ruby. it's still perl that's executing within > js> apache. it is certainly a different context than what you may be used > js> to- but you could say that about windows perl too. > > there are too many differences between a normal perl process and perl > embedded in apache via modperl. ram issues, process copies, sharing > stuff you don't want to share, etc. i am no modperl expert as i stay > away from it.
The first thing that you've said that is correct is that you are no modperl expert. The RAM issues with mod_perl are that if you have many copies of Perl running on the same machine, they take up a lot of RAM. With the number of concurrent requests that typically get served, this becomes a significant consideration. The standard fix is to do as the mod_perl guide says and use a reverse proxy setup in http accelerator mode. At this point mod_perl's memory usage scales quite well. In fact any alternate platform serving the same load will have similar issues at similar volume for the same reasons. The only setup that might scale better with memory is to go asynchronous. Which kills your ability to use multiple CPUs, causes more complex rewrites, deny you the ability to use DBI, and doesn't even save that much memory. (Having the data for 20 people in 1 process takes somewhat less memory than having the data for 20 people in 20 processes, but the difference isn't that big.) Process copies are an architectural decision. With Apache 2 you can choose whether or not to do that. But if you know what you're doing, you'd be silly to choose anything other than pre-fork for Perl on *nix. And the reasons for that have far more to do with Perl than Apache. Sharing stuff you don't want to share is a non-issue if you have properly written code for mod_perl. Conversely any attempt to take CGI code and quickly port it into a persistent environment (ANY persistent environment) will invite that problem. And again, the reasons have nothing to do with Apache. So all of the "mod_perl" issues that you've pointed to are either easily fixed, or had nothing to do with Apache. > sure it has some benefits if you want to get at the > insides of each request but as a computing platform it leaves too much > to be desired. it can't be scaled off the box, you have to worry about > other modules conflicting, you can't run your own event loop or async > ops inside modperl, etc. What do you mean that "it can't be scaled off the box"? If you mean that choosing mod_perl means that you can only have one webserver, then you've demonstrated abysmal ignorance of the state of the art. It is bog standard to have a mod_perl webserver farm sitting behind a load balancer. In fact that has been standard since load balancers were invented. Certainly every serious mod_perl shop that I've heard about in the last decade has used this type of configuration. What you are probably thinking of is how using *shared memory* can tie you to one box. Admittedly many mod_perl sites have made this mistake. However it is a coding mistake you make in Perl, and not a mistake that is tied in any way, shape, or form to your platform, be it mod_perl or otherwise. Furthermore it is a trivial mistake to avoid - just don't rely on local resources like that. Worrying about other modules conflicting, well if you load any Perl process with a bunch of modules then you have to worry about possible conflicts. (Though not very much if they are properly coded, which most are.) Again that concern is not specific to mod_perl. The only thing that you've said that is completely correct is that you can't usefully choose to write your own event loop. And that is because a basic event loop is exactly what Apache provides you. > i could be wrong but i prefer to keep apache as > simple and clean as possible and use perl behind it in stem (or > fastcgi, speedycgi, etc.). then you have total control over your perl > process and no worries about strange things that shouldn't ever matter > but do with apache/modperl. Your being wrong is not just a hypothetical possibility. Your list of "strange things" is a list of FUD that has nothing to do with Apache. > IMNSHO apache is a web server and not an > application platform. merging those two is a major mistake. but of > course many do and many are successful. i think it is the wrong way to > do complex web apps. And you've just demonstrated a mixture of arrogance and ignorance that makes me glad I don't work with you. My only reason for writing this response is that I didn't want anyone to be mislead by your apparent certainty. Regards, Ben _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
