On 2/1/07, Uri Guttman <[EMAIL PROTECTED]> wrote: > >>>>> "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.
WTF do threads have to do with anything? Threads is not a solution that I discussed, nor one that I would advocate using in Perl. Nor are multiple boxes a difficulty for me. Also in a straightforward CRUD application, most of your time is spent in the database. DBI only offers blocking calls. Unless you move DBI off to its own middleware layer, you can't mix DBI and asynchronous programming in a useful way. Finally I never said or indicated that alternatives do mod_perl don't exist and work. I'm saying that your claims that mod_perl DOESN'T work are just solid smoke blown out your ass. > 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. No wonder you are so ignorant on this topic. Right after you just got told that multibox scaling is a complete non-issue with mod_perl, you are repeating your FUD. When you're that resistant to learning basic facts, you're going to remain ignorant. No async is not a weakness, it is a basic design choice. What I mean by that is that ANY platform you choose will push certain assumptions on you. Those assumptions are neither good nor bad, they are just how that platform works. And one of the assumptions that Apache pushes is that it is responsible for the basic event loop, which in turn means you aren't using an asynchronous programming model. On the subject of debugging, I've never seen a problem. Lots of people don't know how to use Apache::Reload on their development servers. And don't provide a development server per programmer. (My development server is, of course, also my desktop...) Those choices would make life harder. And Apache configuration files, while sometimes stupid, are not THAT hard. Besides, you only have to get the configuration right once. After that you don't look at it very often. > 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 If you're disagreeing as a matter of ignorance, that is one thing. When you disagree because you are misinformed as to the tradeoffs, that is another. As a professional you should be interested in figuring out whether your disagreement is the former or the latter. As a fellow professional, I'm informing you that it really looks like the latter. > 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. It looks to me like you are shoehorning reality into a simple religious picture and ignoring the misfit. What am I reminded of here? Oh yes. The great microkernel vs monolithic kernel debate. The idea of microkernels is to divide a kernel into many small parts which are kept nicely isolated from each other. Each one is hopefully simple to design and debug. And then you put them together and you're supposed to get a very good modular system. By contrast a monolithic kernel is designed as one big process. However in practice microkernels are harder to debug, aren't much more reliable, and run significantly slower. And it turns out that it is quite possible for monolithic kernels to be designed in a modular way. The classic comparison (if a bit unfair) is Linux vs HURD. Similarly let's look at Apache. Your complaint about Apache is that it tries to do too much. But in fact it doesn't. Rather it does something fairly simple and then adds the idea of being able to load modules that do other things. And people have written those modules. One of those modules is mod_perl, so you can choose to put Perl into Apache. With mod_perl you can load your own application and you're good to go. By your theory this is bad because it is monolithic. But in practice it is fine because the pieces are modular pieces that are put together in a modular way. And it actually works. > 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. Out of curiousity, what is the busiest website that you are personally responsible for? I need that to get context on how much of your talk about scalability is based on real experience versus theory. For me the answer is http://www.rent.com/, which at peak time serves over a million dynamic pages per hour. Not exactly the biggest site in the world, but not the smallest either. I won't claim that getting there is entirely trivial, you have to know what you are doing. (Note that actually serving that in the real world is very different than serving that in a benchmark. In theory they should be the same, but in practice the messy details of having that many people doing that many different things is a different cup of tea.) > 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. I've learned through experience to NEVER believe a developer's claims about his own code. I'd be interested if you can point to a community of people who have opted to use your code, succeeded without your assistance, and are willing to back up your claims about things like ease of use and scalability. > 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 There are hooks to use it from Perl. In fact if anything there are *too many* hooks. One of the big advantages that PHP has over mod_perl is that hosting providers can have multiple people's PHP code running in the same Apache process with far fewer worries that they will do nasty things to each other. They can't do that with mod_perl because mod_perl access gives people too many opportunities to hijack the Apache process. > 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. True async seems like your religion. In which case enjoy. But mod_perl is not broken or bad because it chooses to use a different paradigm. > >> 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. The number of years of experience you can claim with distributed systems is irrelevant to the question of whether your specific criticisms about mod_perl are right or wrong. The fact is that you stated, and continue to state, things (like no multi-box scaling) that are ludicrously off base. And no matter how much experience you have, and how confidently you state those things, they are still wrong. > we can end this useless thread now if you wish. it has become a > religious argument. I have no real interest in continuing it either. But I disagree that it is a religious argument. It seems that you think that I am arguing that you should use mod_perl. That WOULD be a religious argument. But I'm not. I'm merely saying that the FUD you've been spouting about mod_perl is wrong. Which is a factual argument. Ben _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
