Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Perl Books Media Programming Software The Internet Book Reviews Apache

Practical mod_perl 121

Posted by timothy from the no-swine-in-site dept.
honestpuck writes with the review below of O'Reilly's Practical mod_perl, which he describes as "a doorstop sized volume that provides more information on using mod_perl than you ever thought you needed." Read on for the rest of his review, and to see whether you actually do need to know what's in this book.
Practical mod_perl
author Stas Bekman & Eric Cholet
pages 858
publisher O'Reilly
rating 8 - Good book, some flaws
reviewer Tony Williams
ISBN 0596002270
summary Good overall guide for running and developing with mod_perl

The almost 900 pages are divided into five parts and a bunch of appendices. Part I, "mod_perl Administration" covers building, configuring and installing mod_perl, followed by some Apache details and an 80-page guide to coding with mod_perl in mind. Part II, 'mod_perl Performance' deals with ways of getting the best out of Apache and mod_perl, with a little about security. Part III deals with databases, including persistent connections and data sharing. Part IV is a great guide to debugging and troubleshooting. Part V is a brief look at Apache 2 and mod_perl 2.

The appendices are useful. The first is a short section of around a dozen small 'recipes' for performing various tasks using mod_perl. I found these a good base for more complex tasks, particularly when combined with examples from elsewhere in the book. The second is a list of Perl modules that extend Apache and mod_perl with a brief description of each. The third gives some strategies for providers wanting to host Apache with mod_perl. The fourth and fifth give good overviews of the Template Toolkit and AxKit, an XML application server built on mod_perl.

The book is readable, tending towards heavy writing and certainly dense, but I didn't feel this was a problem in a book meant for a fairly advanced audience. I think you'd want to be a fairly good Perl programmer and well versed in Apache before needing this volume and shouldn't expect to be spoon fed. I thought it well written.

In a book of this size you expect to find a lot of example code, and you won't be disappointed. The book is peppered with short Perl examples and example command lines and configurations, all well explained. The one shortcoming is that there aren't many examples of full-blown applications where you can see everything discussed and have it explained all in one place. I would have appreciated some more of this, the examples tend to be on the short side.

This book sits well in the marketplace. It provides more details on running, installing and configuring mod_perl and Apache than mod_perl Developer's Cookbook (and also delves more into the reasons for doing something one particular way and much more help on debugging), though the Developer's Cookbook becomes a good companion to this volume as it provides a lot more in the way of examples. For those that want to get deep into the high end of mod_perl there is Writing Apache Modules in Perl and C, which is at core a good book on high end mod_perl programming.

O'Reilly have their usual website with Table of Contents, an example chapter, and errata. The authors have their own website with some of the same information and all the code examples from the book as both individual files and one 40k tarball.

I would recommend this book to anyone who administers and writes for mod_perl, it fills the missing pieces in mod_perl Developers Cookbook and is a good companion volume to it.

You can purchase Practical mod_perl from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Practical mod_perl More

Practical mod_perl

Comments Filter:

  • thanks-- (Score:4, Insightful)

    by garysears ( 628452 ) on Monday September 29, 2003 @12:18PM (#7086214)
    Thank you for the review.

    There. Isn't a little common courtesy refreshing?
    • only when its warranted.

      although i think in this case (attempting to summarize a 900 page behemoth) it might be.
    • There. Isn't a little common courtesy refreshing?

      An e-mail to the author would be wonderful (it's on his home page). Posting it on Slashdot isn't a scalable behavior. Just ask, "what would happen if everybody who likes an article posts a 'thank you' note?" Low signal-to-noise ratio, that's what. If these folks also add accolates to their posts, pointing out how wonderful they are, they'll probably receive accusations of karma-whoring or smugness.
      • Arr. yeah.

        When I stepped back to chew over your post, I realize that I agree.

        However, I must say 'thanks' once in a while in a public forum, where the author can get a little approbation in front of his/her audience.

        too much bitterness--lack of sweetness and light.. sugar low-- blacking out...
      • As a matter of policy I agree. But concider how many posts get modded up that are doing nothing but completely trashing the book reviewer. They are almost completely noise as well. It is nice to see some positive noise for a change.

        But even informative posts tend to be negative. The nature of dicussion forums is that signal is information that isn't in the article, so it is just natural that most signal is the opposing view. This results in quite a negative atmosphere. So it's good to have a reminder like
    • Oh, you're sneaky, pretending to be giving a complement, but I see that insult hidden in there. "thanks--"! Why don't you just go all the way and say "thanks=0". Some people, have to throw in their insulting remarks, even when they are pretending to be nice ;)
      • Nope, nope, nope, nope.

        I'm climbin' on my high horse, here.

        every review I've read here gets trashed by people that write as if they're proof that life exists at -6 sigma. Trust me. We and this website will NOT catch fire and die if someone bursts into spontaneous politeness, once in a while, eh? They may hyperventilate a bit, but it's good for you. Just try to STOP breathing for a while.
        • I completely agree, just couldn't pass up a bad C joke. Perhaps this would have been better:

          I see your thanks--, and raise you a thanks++

          err, I made myself groan on that one, perhaps enough bad humor for the day :)

  • general note: what is it (Score:4, Informative)

    by kisrael ( 134664 ) on Monday September 29, 2003 @12:40PM (#7086456) Homepage
    For people who are wondering what mod_perl is exactly: it's a way of integrating perl into Apache's webserver. I think the main advantage is that you don't have the overhead of firing up perl for each cgi-type request. The main gotchas, for the developers point of view, involve a little perl enviornment staying alive, when a perl script starts, runs, and stops, it cleans up after itself, but when it 'stays alive' inside apache, you have to make sure it's not accumulating too much memory cruft, that you're closing handles, etc etc.

    This is what I know mostly by reputation, rather than direct experience, experts please feel free to correct me
    • Yup. The cleanup pretty well takes care of itself if you configure the threads not to be persistent.

      You can attach Perl to Apache by .exe and by .dll...

      how does mod_perl activate? must one compile it in, or is it a configuration switch?

    • Re:general note: what is it (Score:5, Informative)

      by ajs ( 35943 ) <[ajs] [at] [ajs.com]> on Monday September 29, 2003 @01:24PM (#7086912) Homepage Journal
      This is the common view of mod_perl, but it's also rather limited.

      A more general view of mod_perl is that it's the Perl interface to the apache API. This means a lot of things to a lot of different kinds of developers, since the Apache API is so rich. It can be used for any of the following things:

      • Writing one-shot programs that run "close to the server" (this is the primary, and rather limited use of mod_perl).
      • Handling error conditions (e.g. file not found or failed execution)
      • Writing your own page-generation caching system.
      • Writing a content management system (e.g. bricolage)
      • Redirecting requests. One example would be taking a request, examining the cookies, and redirecting based on "user".
      • Proxying. You might, for example, like to proxy part of a request to one back-end and another part to another back-end with a minimum of overhead. That's easy with mod_perl and doesn't require as much work as you might think.
      • SSL certificate integration with database of users.

      You can go on and on with this. The bottom line is that mod_perl isn't really an application builder's toolkit, so much as it's the toolkit-builder's toolkit.

      So many times, I've heard people try to compare mod_perl to full-fledged content management systems, and that's just not what mod_perl is. In fact, it's not even a templating system like PHP. It's just the Apache API mocked up into Perl. Granted, there's more than that. There are some utility features, but if you want templating, look at HTML::Mason. If you want content management, look at bricolage. These are systems build on top of mod_perl, and they will reduce (vastly) the number of wheels you need to re-invent.
      • It can be used for any of the following things:

        I have a couple to add to this. These are ways I have used mod_perl in my current job.
        • Hacks such as cleaning up after Microsoft's broken DAV implementation in Windows XP. If a Windows XP client types in a username and password to authenticate against a DAV share, Windows will prepend SOMEDOMAIN\ to the username. This screws up authentication on the server. However you can write a mod_perl handler that intercepts the request in its early stages and rewri
      • What if you just want perl to run fast on Apache? That's what I'm using it for.
        • What if you just want perl to run fast on Apache? That's what I'm using it for.

          Then mod_perl is the wrong choice.

          However, I suspect you have other constraints that you're not stating that make it more ideal, but still leave other tools (layered on top of mod_perl) as better choices.

          First off, if you just need to add two numbers really fast and return the result via HTTP, you should be writing a C module for apache that does what you want. No need to invoke Perl there.

          If you wanted to write something m

          • What if you just want perl to run fast on Apache? That's what I'm using it for.

            Then mod_perl is the wrong choice.

            No it isn't. You suggest alternatives to writing Perl. If he wants Perl to run fast on Apache, which is what he said, then yes, mod_perl is exactly the way to do that.

            It maintains an in-memory copy of the perl environment, and compiled versions of your scripts. In addition to giving you a lightning-fast perl environment, it also gives you access to Apache's API from Perl if you want it.

            T

  • Stas is the man (Score:4, Informative)

    by jslag ( 21657 ) on Monday September 29, 2003 @12:45PM (#7086499)
    Stas is also behind the excellent online mod_perl guide [apache.org], without which I can't imagine being able to use mod_perl in any kind of production environment. He's a great counterexample for those who complain that nobody puts together proper docs for open source projects.
  • IANAPD (I am not a Perl Developer), but why do you need 900 pages to explain an Apache module?

    Surely, if you'd read the Camel Book and some tutorials/references on the Apache site, you'd be covered?
    • yes, yes, I think that perhaps it is...
    • Naah. It isn't stupid, at all. Have you looked over the docs for Apache? no examples. zip. nada. nothing. I find examples more precious than jewels, for they don't just sit there and glitter, they're useful. Condensed syntax-only guides always leave me suspicious. This isn't FORTRAN66. The syntax is mean.
    • IAAPD (I am a Perl Developer).

      While Learning Perl gets you started pretty quickly and Programming Perl gets you up to speed, there is still a lot to learn about this complex language.

      Likewise, Apache is very complex itself. When you decide to combine them with mod_perl, you have an ever more complex situation to figure out. As one of the other individuals on this thread pointed out, examples are highly prized, and previously there weren't many to be had with a nice detailed explanation. That's the

  • For price comparisons.... (Score:1, Informative)

    by Anonymous Coward
    ...why does anyone look at Amazon and one other store? You'd think there are two book stores online. Try looking here: For a full readout of BestBookBuys' listing on this book (specifically) [bestwebbuys.com]

    There are three good urls for book shopping:

    BookPool [bookpool.com], AddAll [addall.com], BestBookBuys [bestbookbuys.com]. Why not let bots do your shopping? And if you like the newer bots, check out Froogle.Google [google.com]
  • ...that can help make mod_perl Not Suck(tm)? Until we implemented draconian IP blocking measures, the servers we have that run mod_perl (but not our perl code) ran themselves out of swap on a regular basis (several times a day). Similarly bad perl code does little to no damage to servers without mod_perl.

    As an administrator rather than a developer, and as someone who cannot influence what perl goes on the server, was there anything in the book that could help me stop the huge memory footprint per child (th

    • Re:Is there anything in there... (Score:5, Informative)

      by consumer ( 9588 ) on Monday September 29, 2003 @12:54PM (#7086593)
      There are several things that can stop apache children from growing out of control, and yes, they are documented in the book. One thing that helps is the use of modules like Apache::SizeLimit and Apache::ResourceLimit. Another thing that helps is using a proxy server. You also need to set MaxClients correctly. Beyond that, writing code that doesn't suck goes a long way.
      • There are several things that can stop apache children from growing out of control, and yes, they are documented in the book.


        It's one thing when computer lingo results in sentences that are unfathomable by the non-tech types. This is an example of a sentence that's even worse... :)

    • How about programmers that know how to plug leaky code?

      Another option is administrators that know about Apache's MaxRequestsPerChild directive until the leaks are plugged?

      Don't blame the tool for the faults of its users.

    • Re:Is there anything in there... (Score:4, Informative)

      by KMitchell ( 223623 ) on Monday September 29, 2003 @01:20PM (#7086870)
      Not having read this book yet (though I just ordered it), I don't know if there's anything in the book to help you, but there ARE some things you can do with just access to httpd.conf.

      Since mod_perl compiles the perl code and keeps it resident in your apache children, code that isn't designed for mod_perl can eat a ton of memory. It's often pretty straightforward to fix this kind of thing, often just by "preloading" some modules. Taking it at face value that you have ABSOLUTELY no control of what code is running on your server, what you need to do is have Apache limit how big Apache children can grow.

      Check out the mod_perl docs on child memory size http://perl.apache.org/docs/1.0/guide/performance. html#Preventing_Your_Processes_from_Growing

      Summarizing, play with MaxRequestsPerChild if you're "in a hurry" and check out Apache::SizeLimit or Apache::GTopLimit if you have the time/inclination to do something less heavy handed.
    • Along these lines, if your preloading large modules (say CGI) in httpd.conf or whatever, then those modules will be shared reducing footprint, do this smartly and you should get a decent child size if you take away the shared portion.

      As to your other problems.... I would get new perl programmers (not that it sounds like that is up to you). The "problem" with mod_perl is that it gives you access to apache at a very low level and that power can be missused rather easily. use strict;

    • Switch away from Solaris?

      Just a guess. But Solaris needs dramatically more swap than Linux for the same amount of Apache processes. That's because Solaris does not allow you to overcommit memory. Not even if you really really want it, because you know all those Apache processes share a lot of pages.
    • Yes, MaxClients in the apachge configuration. See who much RAM you have in the box, see how much each apache process is taking up, divide the one by the other to get a rough figure for maxclients. Tune until you don't swap any more.

      Having less processes is not really a problem. Newer connections will just be accepted by the kernel and apache will pick them up when it's ready. As to mod_perl taking up more memory, that's expected behaviour. I've got 25Mb mod_perl processes, but no problems because I'v


  • I used to love ModPerl back when I wrote for Unix systems. I thought it was, unlike ASP, simple and elegant. But now it seems like Php is more "in vogue". Is modPerl still actively used as the preferred way to get scalable web server performance?

    • Re:ModPerl vs Php? (Score:3, Informative)

      by consumer ( 9588 )
      mod_perl is used at many sites, including ticketmaster.com and citysearch.com. It has better performance than PHP. Amazon is using Perl with FastCGI, which is pretty much the same thing as mod_perl with a proxy server.

      • Re:ModPerl vs Php? (Score:4, Informative)

        by Neil Watson ( 60859 ) on Monday September 29, 2003 @01:29PM (#7086958) Homepage
        Amazon also uses Mason [masonhq.com]. See here [theaimsgroup.com]. Although, IIRC mod_perl is required for Mason.

        • Mason is indeed best run with mod_perl and it's definitely the least painful way of using it, not to even mention most aesthetically pleasing.

          Mason can be used through a CGI script, too - basically, you make a CGI script to be an apache Action, and then just set-handler your files to it. Setup might be tricky, but it works.

          If you get reasonably bored with ordinary every-day templating modules, you can even run Mason stand-alone (you can simply make an instance of HTML::Mason::Interp and there you go...)

    • they are crud

      If you want performance, rm -f /usr/local/etc/apache

    • Re:ModPerl vs Php? (Score:3, Interesting)

      by hondo77 ( 324058 )

      Is modPerl still actively used as the preferred way to get scalable web server performance?

      We're using it. It's big advantage over PHP is that I write Perl code instead of PHP. Sorry but I just don't like PHP itself.

    • I'm sorry, but if you spell mod_perl "ModPerl" you just didn't use to "love it."
  • It would have been nice if they could have found room to cover HTML::Mason [masonhq.com] as well as Template Toolkit and AxKit. Mason is a very popular module for templating and devloping web applications.
    I know they can only have room for so much but at 900 pages it's not like they were not shy of a big book.
    • We would have loved too, and in fact had several appendices covering various other popular toolkits used on top of mod_perl, but there's a point where you can't just keep on adding material--our editor decided for us that this point was reached at 900 pages.
      --Eric, co-author
      • That's fair enough. I was going to ask why the book was not rewritten to use less space so as to fit in extra stuff about Mason but you might reasonably tell me to go to hell. ;-)
        Enjoyed flicking through the sample chapter on the Web, it's a nicely written book.

  • Perl, and web security documentation (Score:1, Informative)

    by Anonymous Coward

    www.cgisecurity.com/lib/ [cgisecurity.com]
  • The whole reason I use Perl is to hack out stuff quick and easy with minimul effort. The day I spend time reading about it is the day I read about better ways to masterbate. ;)
  • Too bad there seems to be only one chapter on mod_perl 2.0. It's still a (slightly?) moving target, but it seems very promising and is hopefully stable soon, leading to a large number of people switching to Apache 2.x.
    After all, everyone is itching to have the various filters chained after one another, like running Apache's server side include mechanism over the output of your perl scripts... which is possible only with Apache 2.x.

  • Good book, but for us noobies more examples are needed.

    kris@maficstudios.com [mailto]
    sales@maficstudios.com [mailto]
    jobs@maficstudios.com [mailto]

Slashdot Top Deals

Single tasking: Just Say No.

Close