NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
use Perl Log In
geoff (2013)
geoff
reversethis-{gro ... om} {ta} {ffoeg}
http://www.modperlcookbook.org/
see http://www.modperlcookbook.org/~geoff/ [modperlcookbook.org] for personal information, links to presentations, GPG key, and so on.
reversethis-{gro ... om} {ta} {ffoeg}
http://www.modperlcookbook.org/
see http://www.modperlcookbook.org/~geoff/ [modperlcookbook.org] for personal information, links to presentations, GPG key, and so on.
Monday August 25, 2003
01:15 PM
misunderstanding the technology
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*
"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*
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Or is it a BUG?"
"Let's call it an accidental feature. :-)"
--Larry Wall in <6909@jpl-devvax.JPL.NASA.GOV>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
the sadness runs deeper than you think (Score:2, Insightful)
Re:the sadness runs deeper than you think (Score:2, Interesting)
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
rebuttal (Score:3, Informative)
The problem with the new cpanratings is there is no way to rebut a review that is just plain wrong.
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 :)
Reply to This
Re:rebuttal (Score:1)
sky
Re:rebuttal (Score:3, Interesting)
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.
- ask
-- ask bjoern hansen [askbjoernhansen.com], !try; do();
Re:rebuttal (Score:2)
I like that idea. I'll have to see if I can get combust working this weekend then...
I'm not sure the Apache API matters very much (Score:1)
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 opti