The original poster talked about C++ CGI programs. I have been using mod_perl since 0.7x days and I can tell you there is no way a fork+exec CGI program no matter what language its written in will come anywhere close to a perl handler written against the mod_perl Apache API in execution speed (when they are doing equivalnet types of work). Using C++ to build web applications is something developers who grew up in the heyday of client server would think is a good idea. In the internet web applications business by the time you get a C++ program debugged and ready to roll the market has evolved and your software is out of date. C++ is a good language for systems programming, databases, etc., but web apps need shorter life cycles.
I had an investor question similar to the one we are talking about 3 years ago. I was questioned as to why we used Apache, mod_perl, and mysql instead of C++ and Oracle's DB and Web Devel kit. Needless to say our mod_perl systems have thrived while most of the investor's other investments have had their expensive hardware auctioned off on Ebay recently. The essence of mod_perl is that it allows to to take an idea and build a working prototype very quickly. When you prove that the prototype works you don't need to rewrite - mod_perl scales up better than any other web application technology available - period. -jon On Fri, 14 Dec 2001 [EMAIL PROTECTED] wrote: > > > -- Jeff Yoak <[EMAIL PROTECTED]> on 12/14/01 12:58:51 -0800 > > > 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. > > Constructing the $r object in perl-space is an overhead > that mod_perl causes. This overhead has been managed more > effectively in recent versions of perl/mod_perl. A study > done "a few years ago" probably involved machines with > significantly less core and CPU horsepower than the average > kiddie-games PC does today. Net result is that any overhead > caused by mod_perl in the previous study may well have been > either mitigated with better code or obviated by faster > hardware [how's that for a sentence?]. > > Net result is that the objection is probably based on once- > valid but now out of date analysis. > > -- > Steven Lembark 2930 W. Palmer > Workhorse Computing Chicago, IL 60647 > +1 800 762 1582 > -- C. Jon Larsen Chief Technology Officer, Richweb.com (804.307.6939) SMTP: [EMAIL PROTECTED] (http://richweb.com/cjl_pgp_pub_key.txt) Richweb.com: Designing Open Source Internet Business Solutions since 1995 Building Safe, Secure, Reliable Cisco-Powered Networks since 1995
