Stories
Slash Boxes
Comments
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

Log In

[ Create a new account ]

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.

Journal of geoff (2013)

Monday August 25, 2003
01:15 PM

misunderstanding the technology

[ #14311 ]
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 Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • unfortunately this kind of clouded view of mod_perl is pervasive throughout the industry. in my company, where i'm surrounded by java-ites (*shudder*), i mention mod_perl, and people immediately think CGI and discount it. in the meantime, it's silently driving half of our internal infrastructure applications. :)
    • 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

  • rebuttal (Score:3, Informative)

    by gav (2710) on 2003.08.25 13:38 (#23473) Homepage Journal

    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 :)

    • or use mod_perl2 and threaded mpm :)
      --
      sky
    • Re:rebuttal (Score:3, Interesting)

      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.

        - ask
      --

      -- ask bjoern hansen [askbjoernhansen.com], !try; do();

      • 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...

  • Seriously, what do we gain from it? The ability to do auth modules? That's available in FastCGI as well. Cleanup handlers are very helpful, but I can't think of much else that is truly unique to mod_perl because of the API access.

    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