On Fri, Dec 14, 2001 at 12:58:51PM -0800, Jeff Yoak wrote: > At 09:15 PM 12/14/2001 +0100, Thomas Eibner wrote: > >The key to mod_perl development is speed, there are numerous testimonials > >from users implementing a lot of work in a very short time with mod_perl. > >Ask the clients investor wheter he wants to pay for having everything you > >did rewritten as an Apache module in C. That is very likely going to take > >a lot of time. > > Thank you for your reply. I realized in reading it that my tone leads one > to the common image of a buzzword driven doody-head who wants this because > of what he read in Byte. That's certainly common enough, and I've never > had a problem dealing with such types. (Well... not an unsolvable > problem... :-)
True, it sounded a bit like that. > 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. I'm wondering where the investor have been hiding if he isn't telling you this until now. It's hard to pull on resources that you have no idea are available to you. If he did the comparision years ago he should be doing his tests over again, since a lot of things have happened over the last few years. From what you write it seems to me that he can't just be using plain CGI in C, since it still has the fork overhead that mod_perl doesn't and even a small hello world test would prove that mod_perl is faster there (I didn't try it, but I'm sure we could make some tests). Although you haven't told us much about what the actual application you wrote for your client does, I must say that I've found it more error prone and time-consuming doing any database stuff in C. I'm not a C programmer of heart, but I have done a fair amount of programming with it and it certainly hasn't been as fast to develop as applications relying on DBI. You haven't told us what you normally program in either, so we don't know if you do mod_perl most of the time or you just write your stuff in C regulary, this could also have an impact on the length of the project in the end. > 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. To me it seems like he should be upset with himself. If he knows he has some good tools he should have told your client way before this project even started anyway. > 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. I certainly hope that you find something that will show him that mod_perl isn't a bad choice. -- Thomas Eibner <http://thomas.eibner.dk/> DnsZone <http://dnszone.org/> mod_pointer <http://stderr.net/mod_pointer>
