Slashdot Mirror
Practical 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 book is also the first book to cover the "next generation" of mod_perl: mod_perl 2.0, a completely rewritten version of mod_perl designed for integration with Apache 2.0, which for the first time supports threads.
The book covers the following topics, and more:
Configuring mod_perl optimally for your web site
Porting and optimizing programs for a mod_perl environment
Performance tuning: getting the very fastest performance from your site
Controlling and monitoring the server to circumvent crashes and clogs
Integrating with databases efficiently and painlessly
Debugging tips and tricks
Maximizing security
Written for Perl web developers and web administrators, Practical mod_perl is an extensive guide to the nuts and bolts of the powerful and popular combination of Apache and mod_perl. From writing and debugging scripts to keeping your server running without failures, the techniques in this book will help you squeeze every ounce of power out of your server. True to its title, this is the practical guide to mod_perl.
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
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
this, get it sorted please, mods.
I have over 70 freaks, do you?
Stas is also behind the excellent online mod_perl guide, 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.
...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)
There are three good urls for book shopping:
BookPool, AddAll, BestBookBuys. Why not let bots do your shopping? And if you like the newer bots, check out Froogle.Google
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.
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.
www.cgisecurity.com/lib/
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.
. html#Preventing_Your_Processes_from_Growing
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
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;
Amazon also uses Mason. See here. Although, IIRC mod_perl is required for Mason.
UNIX/Linux Consulting