I was deeply saddened by a review of mod_perl on cpanratings. to quote part of it
"the only thing that mod_perl has going for it is that it is widely known and a lot of material and modules have been written for it.
Architecturally, it's a poor choice for building dynamic web applications. The problem is that the same process(es) are serving simple files as well as generating dynamic pages. This means that while images, etc are being served to clients by apache processes, all of the memory consumed by the Perl interpreter is essentially wasted.
There is a binary optimized, Open Market standard that was designed for just this - FastCGI.
It is for these reasons that I hold my opinion that Apache/mod_perl will be one day seen in the same light as Sendmail - filled with the cruft of years of creeping featuritis.
now, to be fair, the criticisms he raises inbetween are valid - most are part of the price you pay for the technology. however, what really irks me is that the myth that mod_perl and FastCGI (or anything else, for that matter) are equivalent technologies - it's the access to the Apache API in Perl that makes mod_perl unique, something that is simply unparalleled anyplace else.
mod_perl offers complete access to the Apache C API in Perl.
it's the thought that people don't understand this, despite all the literature and advocacy out there, that really saddens me.
*sigh*
Re:the sadness runs deeper than you think
rob_au on 2003-08-26T10:45:12
in the meantime, it's silently driving half of our internal infrastructure applications.This is such a true anecdote - For a new project which I have been developing internally, I was able to leverage a fully functional prototype server using mod_perl and a handful of proprietary modules within three days of development time. In all likelihood this prototype will continue to use mod_perl when it is shifted into a live environment because of the rich framework and flexibility which this framework already provides - I shudder to think of the amount of work which would be required to replace this element of the solution.
The problem with the new cpanratings is there is no way to rebut a review that is just plain wrong.
The problem is that the same process(es) are serving simple files as well as generating dynamic pages. This means that while images, etc are being served to clients by apache processes, all of the memory consumed by the Perl interpreter is essentially wasted.
This is a well-known problem that effects more than just mod_perl. The solution is pretty simple, you use a reverse proxy, either running another instance of Apache on the same box or a seperate one. Plus memory is cheap these days anyway
Re:rebuttal
sky on 2003-08-25T20:59:55
or use mod_perl2 and threaded mpm:) Re:rebuttal
ask on 2003-08-26T02:34:49
The problem with the new cpanratings is there is no way to rebut a review that is just plain wrong.
That's a feature. I don't want it to turn into a discussion forum.
Write another review and point out that those things are not correct. In the future (patches welcome!) you'll be able to rate reviews helpful or not helpful.
- askRe:rebuttal
gav on 2003-08-26T02:55:52
In the future (patches welcome!) you'll be able to rate reviews helpful or not helpful.I like that idea. I'll have to see if I can get combust working this weekend then...
I don't agree with Sam's review though. A front-end proxy is almost exactly equivalent to using FastCGI. He's also got outdated info about Squid: it doesn't beat apache as a static server and proxy, and it hasn't for years.
More to the point, FastCGI is just not a viable option for most people these days. It is not very well supported (documentation is quite weak) at this point and essentially doesn't work at all for Perl on Windows. It's simply out of reach for the masses unless someone puts a lot of effort into it. A better mod_perl alternative would be SpeedyCGI aka PersistentPerl, since it doesn't require root priveleges and is thus well-suited for ISPs, but it doesn't seem to be very active either these days.
