Mod_perl doesn't suck, and it certainly doesn't have a huge hit on the CPU. (of course it all depends what you're doing, but for the most part it's small)
Having used many high level web development environments, from C to Java to TCL and perl, I find mod_perl at the top end of the scalability scale. Plenty of fast and heavily loaded sites use mod_perl without throwing tonnes of hardware at it, AND as a side bonus, chances are the development time was faster than writing in almost anyything else. I run a wee little web site, it runs on 4 servers (1 static server, 2 mysql servers, and one mod_perl server) all told, this hardware cost about $10k usd. Yesterday, the site served 2,000,000 page loads (ads, impressions, how every you count it), with about 6 Million requests to the mod_perl server, which in turn passed on about 200 Million requests to the DB server. Yes, I struggle with performance, but under most other development environments I'd have been up against the wall a long time ago. Mod_perl is NOT CPU intensive. It IS memory intensive. Due to the architecture of apache, and the memory overhead some care must be taken when planning a large capacity site, but fortunately all of this is nicely documented in the guide. There are other solutions. Yes, I suppose I could rewrite large parts of the site in C. It certainly wouldn't help with development (which is always patching this, adding feature Z), it might, maybe reduce some of the memory overhead. My largest challenge has actually been to get mysql (written in C) to properly handle it's share of the workload. Take a perusal at the Stories section on perl.apache.org http://perl.apache.org/stories/ ValueClick serves an incredible number of impressions via their mod_perl systems. It scales, it's fast, and it doesn't take a lot of hardware. --A > -----Original Message----- > From: Jeff Yoak [mailto:[EMAIL PROTECTED]] > This is something different. The investor is in a related > business, and > has developed substantially similar software for years. And > it is really > good. What's worse is that my normal, biggest argument isn't > compelling in > this case, that by the time this would be done in C, I'd be > doing contract > work on Mars. The investor claims to have evaluated Perl vs. > C years ago, > to have witnessed that every single hit on the webserver > under mod_perl > causes a CPU usage spike that isn't seen with C, and that > under heavy load > mod_perl completely falls apart where C doesn't. (This code > is, of course, > LONG gone so I can't evaluate it for whether the C was good > and the Perl > was screwy.) At any rate, because of this, he's spent years > having good > stuff written in C. Unbeknownst to either me or my client, both this > software and its developer were available to us, so in this > case it would > have been faster, cheaper and honestly even better, by which > I mean more > fully-featured. > > So he's upset. Everyone acknowledges that given our particular > circumstances, it would have been better to build upon what > we already had, > but because of his previous experience he feels that mod_perl > wasn't even a > responsible choice even within the limits of our lack of > knowledge of his > software and its availability. > > So I'm trying to show that mod_perl doesn't suck, and that it > is, in fact, > a reasonable choice. Though within these limits it is still > reasonable to > point out the development cycle, emotionally it is the least > compelling > form of argument, because the investor has a hard time removing from > consideration that given our particular situation, there was > a very fast > solution in using his C-based routines.
