>>>>> "BT" == Ben Tilly <[EMAIL PROTECTED]> writes:
BT> At this point mod_perl's memory usage scales quite well. In fact any BT> alternate platform serving the same load will have similar issues at BT> similar volume for the same reasons. The only setup that might scale BT> better with memory is to go asynchronous. Which kills your ability to BT> use multiple CPUs, causes more complex rewrites, deny you the ability BT> to use DBI, and doesn't even save that much memory. (Having the data BT> for 20 people in 1 process takes somewhat less memory than having the BT> data for 20 people in 20 processes, but the difference isn't that BT> big.) you can use multiple cpus, async ops, dbi all in a middleware layer behind apache. been there, done that with stem and it worked great. and it was multiple boxes to boot (threads have slight problems with that :). there are many ways to scale and threads is just one narrow solution IMO. they have their point but ain't no silver bullet. BT> Process copies are an architectural decision. With Apache 2 you BT> can choose whether or not to do that. But if you know what you're BT> doing, you'd be silly to choose anything other than pre-fork for BT> Perl on *nix. And the reasons for that have far more to do with BT> Perl than Apache. still limited to no async, no multibox scaling. the whole architecture of apache as an app platform is the issue. but it works for many and i won't go that route. i like more control over my systems and having easier time of debugging and all the rest. also no massive craziness with apache config files. BT> So all of the "mod_perl" issues that you've pointed to are either BT> easily fixed, or had nothing to do with Apache. i professionally and politely disagree. but that is my right. apache is a web/http server and a fine one at that. beyond that it is insane to do anything with it. ever heard of isolation? glomming more and more onto a system is how redmond develops. want apache to be the new winblows? people complain about emacs that way too (and i use emacs). you can't have one system try to be the end all. it is not a good idea and that has been proven time and time again. apache won't be able to sustain this for all applications for all users. so why no just get out of apache asap and do the real work behind it. let apache handle http, static files, url munging and those sort of things best done directly in the web server. asking it to do all the app stuff is just wrong, no matter how they implement it or whether it may work or not. the high level picture is wrong. BT> What do you mean that "it can't be scaled off the box"? If you mean BT> that choosing mod_perl means that you can only have one webserver, BT> then you've demonstrated abysmal ignorance of the state of the art. BT> It is bog standard to have a mod_perl webserver farm sitting behind a BT> load balancer. In fact that has been standard since load balancers BT> were invented. Certainly every serious mod_perl shop that I've heard BT> about in the last decade has used this type of configuration. no, i don't mean one webserver. i mean scaling with other issues as well as just front end serving. state, sessions, db handles, etc. sure it can all be done in apache now but as i said above, it breaks the isolation idea and that is more important to me. BT> Worrying about other modules conflicting, well if you load any Perl BT> process with a bunch of modules then you have to worry about possible BT> conflicts. (Though not very much if they are properly coded, which BT> most are.) Again that concern is not specific to mod_perl. perl modules can be more easily fixed and such. badly written c code is much harder to deal with. and with proper design (and not using half of cpan) you can do that in perl. but what would i know as i have already done that. :) stem is only 10k lines of code and does the equvilent of many more and much larger amounts of cpan code with more isolation, speed, clean code, cleaner apis and easier interconnectivity and scaling. this is due to an architectural design the aims for that. async is core including async flow control which is not easily done. BT> The only thing that you've said that is completely correct is that you BT> can't usefully choose to write your own event loop. And that is BT> because a basic event loop is exactly what Apache provides you. are there hooks to use it from perl? and most cpan modules are written sync or have their own useless (no hooks) event loops like lwp::parallel. true async systems need to be designed that way and i don't think you will get that from apache/perl. >> 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. BT> And you've just demonstrated a mixture of arrogance and ignorance BT> that makes me glad I don't work with you. My only reason for BT> writing this response is that I didn't want anyone to be mislead BT> by your apparent certainty. i can say the same back. it isn't certainty but long term experience on how to architect distributed and async systems. this is not something i dabble in but have been doing for over 25 years from asm to c to perl. i do know a slight amount about them but you can dispute that all you want. i would put a stem middleware design against any modperl design. just one more win is that design is web server agnostic as well. we can end this useless thread now if you wish. it has become a religious argument. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
