Slashdot Mirror
mod_perl Developer's Cookbook
This book uses the popular "cookbook" approach, where the content is broken down into short "recipes" each of which addresses a specific problem. There are almost two hundred of these recipes in the book arranged into chapters which discuss particular areas of mod_perl development. In my opinion the cookbook approach works much better in some chapters than in others.
It's the start of the book where the cookbook approach seems most forced. In chapter 1 problems like "You want to compile and build mod_perl from source on a Unix platform" provide slightly awkward introductions to explanations about obtaining and installing mod_perl on various platforms (kudos to the authors for being up-to-date enough to include OS X in the list). All the information you want is there however, so by the end of the chapter you'll have mod_perl up and running.
Chapter 2 looks at configuration options. It tell you how to get your CGI programs running under mod_perl using the Apache::Registry module which simulates a standard CGI environment so that your CGI programs can run almost unchanged. This will give you an immediate performance increase as you no longer have the performance hit of starting up a Perl interpreter each time one of your CGI programs is run. This chapter also addresses issues like caching database connections and using mod_perl as a proxy server.
We then get to part II of the book. In this section we look at the mod_perl API which gives us to the full functionality of Apache. This allows us to write Perl code which is executed at any time during any of the stages of Apache's processing.
Chapter 3 introduces the Apache request object which is at the heart of the API and discusses various ways to get useful information both out of and back into the object. Chapter 4 serves a similar purpose for the Apache server object which contains information about the web server and its configuration.
In chapter 5 the authors look at Uniform Resource Identifiers (URIs) and discuss many methods for processing them. Chapter 6 moves from the logical world of URIs to the physical world of files. This chapter starts by explaining the Apache::File module before looking at many ways to handle files in mod_perl.
The previous few chapters have built up a useful toolkit of techniques to use in a mod_perl environment, in chapters 7 and 8 we start to pull those techniques together and look in more detail at creating handlers - which are the building blocks of mod_perl applications. Chapter 7 deal with the creation of handlers and chapter 8 looks at how you can interact with them to build a complete application.
Chapter 9 is one of the most useful chapters in the book as it deals with benchmarking and tuning mod_perl applications. It serves as a useful guide to a number of techniques for squeezing the last drops of performance out of your web site. Chapter 10 is a useful introduction to using Object Oriented Perl to create your handlers. While the information is all good, this is, unfortunately, another chapter where the cookbook format seems a little strained.
Part III of the book goes into great detail about the Apache lifecycle. Each chapter looks at a small number of Apache's processing stages and suggests ways that handlers can be used during that stage. This is the widest ranging part of the book and it's full of example code that really demonstrates the power of the Apache API. I'll just mention one particular chapter in this section. Chapter 15 talks about the content generation phrase. This is the phase that creates the actual content that goes back to the user's browser and, as such, is the most important phase of the whole transaction. I was particularly pleased to see that the authors took up most of this chapter looking at methods that separate the actual data from the presentation. They have at recipes that look at all of the commonly used Perl templating systems and a few more recipes cover the generation of output from XML.
Finally, two appendices give a brief reference to mod_perl hooks, build flags and constants and a third gives a good selection of pointers to further resources.
This is the book that mod_perl programmers have been waiting for. The three authors are all well-known experts in the field and it's great that they have shared their knowledge through this book. If you write mod_perl applications, then you really should read this book.
You can purchase mod_perl Developer's Cookbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
It doesn't actually add much to the info already available at CPAN. Still nice to have it on the shelve.
!ERR: Signature not found.
I appreciate the reviewers candor, but couldn't he have done a more thorough review instead of just focusing on some of the book???
Do you want to remove linux?
mod_perl provides a means for transparently wrapping CGI programs so that they run continuously instead of starting up (and thus parsing) every time a request requirest them.
However, it's much more than a CGI accelerator. It provides hooks into all of the stages of an apache transation.
As an example of the kind of power this gives you, you can write a Perl plugin for Apache that intercepts 404s, and generates a dynamic page which you then cache to disk for future access (far out-stripping even native C dynamic page generation speeds on subsequent hits). This is just one example. You can write whole content management systems using mod_perl, and in fact many have.
www.cgisecurity.com/lib
we (the authors) support a companion website where you can find a number of useful items, such as all the code from the book (to save your fingers) and a full-text search engine (to supplement the index).
http://www.modperlcookbook.org/
enjoy
PHP is fine, but it's not as fast as mod_perl.
PHP is so gay it's endorsed by Richard Simmons.
[disclaimer: author post follows]
The problem with CPAN is knowing what's useful and what's not. This book isn't just a collection of modules and documentation. Instead it's geared to people who are writing mod_perl code. The code examples are used to show you not just how to do some task, but also (in most cases) how the code does what it does.
In fact, distilling mod_perl code into short, sweet examples was where most of the effort went into writing this book. You don't want pages and pages of code to illustrate one or two simple ideas.
So, perhaps we didn't write a book that was useful to you. Given the feedback I've read, it is useful to many other people.
it's taken /. a while as well; this book was published in January
In any case, it's nice to see a new review on one of my favorite web sites. More good reviews over there at amazon and at the book's official web site.
It's partly my fault. I got my review copy in June :-/
http://www.modperlcookbook.org/modperl2.html
One thing to note is that it is for the 1.3 version not the new 2.0 version. They say though there are not too many differences.
You raise a valid point: CPAN is overwhelming because it is (in essence) a disorganized heap of information. I'm sure the book helps a great many people that do not have time and/or skills and/or need to look it al up for themselves. Distilling the info into a more pallatable format is a Good Thing. The fact remains however that for me there is not much news in the book. As I said before, but in different order, it's a nice book to have on the shelve, but (for me) there isn't much of an addition to CPAN.
!ERR: Signature not found.
This book's approach helps me find tried and true approaches to the things I need to make mod_perl do. It's far better organized and written than the freely available documentation and covers a range of modules (many written for the book) that do things I used to do the hard way. It's clear, concise, and the material is well chosen. You'll get a lot further along on your next mod_perl project a lot faster with this book close to hand than by repeatedly scouring CPAN and the web for the modules, mail messages, and documentation
Yours in mod_perl,
Barrie
I picked this book up in B & N at least 2 months ago.
The first mod perl book? What about Writing Apache Modules with Perl and C by Lincoln Stein? March 1999. Covered mod_perl for faster CGI as well as extending apache directly. And included a nice reference which I still use.
Maybe this book has a few more examples of mod perl, but not covering Apache 2.0 and mod_perl 2 kinda dates it as we won't be in 1.3 much longer. And the changes in Apache 2.0 open up much more that "a few changes". Sure you could port something with a few changes, but you'll miss alot of the cool stuff od 2.0.
Mike
The first mod perl book?
I think he meant the first of those books to come out this year, with Practical mod_perl being at least one other due out before the year is up.
we won't be in 1.3 much longer
that depends on a number of factors, not the least of which is that it takes real systems far longer to migrate to a new software version than it takes bleeding-edge developers.
The biggest problem with mod_perl is that it is such a memory hog. Can anyone explain me why a simple script of 100 lines takes in the order of 10 megs of RAM - and that's just one Apache child - when you usually need 50-100 of them. Even if most of the code is loaded in the parent process and thus is supposed to be shared between children, after a short while memory pages in Apache children start to split due to Perl's handling of module variables, so it's quite useless overall.
As such mod_perl is totally unusable in shared hosting environments: if you load scripts from different users into one server, they start to trample on each other's namespaces: too bad mod_perl doesn't have any provisions for forceful namespace separation between virtual hosts.
Mod_perl has been around for more than 5 years, and the quality of the code is still mediocre, there are subtle problems in more than few places unfortunately (of course most of them are the result of Perl5 as a mediocre programming language for this type of application). Good documentation: practically non-existent aside from a performance guide by Stas.
Ease of use: close to 0 out of 10 - mod_perl is nothing more than a perl interface to the Apache C internals and is really more a platform than a product. While it has some shortcuts for simply wrapping your olde CGI scripts and speeding them up considerably (DB connection caching is the second best feature), not that many people will actually use mod_perl until it has some kind of a app server product that is makes using mod_perl easy, PHP is by far the best starting point for most people and maybe 10% of them will ever get to a point where switching to mod_perl actully makes sense for them for one reason or another - and when they do it's usually a switch to Perl over PHP.
I don't have the money to pay for my own dedicated server. Is there anywhere that I can get access to mod_perl for $10-20/month?
. html
I know what you are probably thinking, If my site is small enough to get by on a virtual hosting account, than I should probably just not worry about mod_perl. And maybe I should just leave it at that but here is what I am thinking...
I am not a mod_perl expert so I might be totally wrong about this but, hey, that's why I'm asking! If a host setup mod_perl with some basic modules preloaded users could then run their scripts under it. Not only would user's websites run faster but it would reduce system resources (overall) which should make the hosting company happy too.
Yes, I know that there would be some problems particularly with security but has anyone figured out a way to do this successfully?
REF: http://www.perl.com/pub/a/2002/05/22/mod_perl-isp
As should be expected, PHP and mod_perl both use a considerably smaller amount of memory than others in the benchmark you reference.
PHP has a small edge in database queries, while mod_perl has a small edge in logic efficiency and i/o.
I would consider both to be professional-grade Web scripting languages and would recommend people choose their favorite based on which they find easiest to code with. For a lot of Perl developers, that is going to be mod_perl.
no offense to the authors of this fine book, but isn't it about - oh i dont know - 3 years late???
The guy wrote Gopher, and now he's a mod_perl guru. Great guy to learn from, this book is a great read (I like "Writing Apache Modules with Perl and C" as well)....
Anyone really interested in mod_perl should check out their mailing list, I have been on it for a few years now, best signal to noise ratio for a technical discussion area ever...
-R.Dietrich
Not to knock Perl, but have you ever tried to maintain someone else's CGI scripts? Perl has a serious design flaw in my opinion - it's easy to write code that is almost unreadable to anyone else but the author.
As a System Administrator, I see this as being detrimental to the work environment - so you have a Perl guru who can do it all - what happens when they leave? Who will you replace them with? How long will the new people need to familiarize themselves with obfuscated code?
Consider a solution like Python or PHP. PHP quite simply is the shit when it comes to web programming - you can quickly put together a complex web application using its straightforward and simple syntax, which is easy to read, understand and modify. (Of course you all know this...)
Python is even better in this regard.
In a production environment, it makes sense to use tools that are conducive to efficiency.
My motto: Keep It Simple Stupid!
A small edge in what way? And do you have any benchmarks if it is performance wise?
If you want speedy prototyping of SQL enabled webpages, RXML from Roxen (GPL) beats them all Open Source solutions (database and host is specified in config file):
Equivalent code from mod_perl and PHP might be slightly faster, but this is higher level, easier to maintain code (once you understand the XML based RXML).You should read the post I was replying to.
I did not make up these results, nor do I stand behind them. The results seem valid to me, because they simply reaffirm my suspicions.
Yours obviously differ.
This is by far one of the most useful books on my bookshelf. If you have a problem just pick it up, thumb through it a bit, and find the answer. Its approach, which is very different form that of the Eagle book, was sorely needed for a long while.
Radioactive cats have 18 half-lives.
PerlRun is the component that allows CGI to be run without modification, not Registry.
--- Robert Strickland
i haven't seen the book around my regular sydney bookshop, but then i generally tend to linger in the ora section... but i will certainly seek this one out.
to those who would say that perl is useless and unmaintainable beyond your basic 2K-line shopping cart application - i have 125K-lines of OO mod_perl app (not counting any CPAN modules!) which would argue otherwise. i would say that this app is *more* maintainable than its java equivalent by virtue of the fact that perl is so much more expressive (and therefore easy to grok) than java (which is exceedingly verbose and clumsy IMHO). and while the running footprint for this app is large (~25meg/process), it does a hell of work and request/response times are still very good (though i would kill to be able to dynamically unload large, rarely-used modules in perl as easy as it is to dynamically load them).
matt