Practical mod_perl

← Back to Stories (view on slashdot.org)

Posted by timothy on Monday September 29, 2003 @05:15AM 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.

121 comments

Min score:

Reason:

Sort:

$5 cheaper and FREE shipping by Anonymous Coward · 2003-09-29 05:16 · Score: 0

Ref:Amazon has this book for $5 less than bn and with free shipping
1. Re:$5 cheaper and FREE shipping by Anonymous Coward · 2003-09-29 05:20 · Score: 0
  
  This pro-software-patent troll brought to you by ccats.
2. Re:$5 cheaper and FREE shipping by Anonymous Coward · 2003-09-29 05:34 · Score: 0
  
  Don't worry, you'll pay that $5 and more at all the other stores that have to pay Amazon payment royalties for their "inventions".
Perl by KermMartian · 2003-09-29 05:17 · Score: 0, Flamebait

Probably be a good idea to read this in order to find out more about Perl...er, wait, make that >find out about Perl in the first place!
thanks-- by garysears · 2003-09-29 05:18 · Score: 4, Insightful

Thank you for the review.

There. Isn't a little common courtesy refreshing?
1. Re:thanks-- by rootofevil · 2003-09-29 05:24 · Score: 1
  
  only when its warranted.
  
  although i think in this case (attempting to summarize a 900 page behemoth) it might be.
  
  --
  turn up the jukebox and tell me a lie
2. Re:thanks-- by Anonymous Coward · 2003-09-29 06:04 · Score: 0
  
  you sir, are a hellbound heretic!
  
  turn or burn.
3. Re:thanks-- by bill_mcgonigle · 2003-09-29 06:20 · Score: 1
  
  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.
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
4. Re:thanks-- by pavon · 2003-09-29 06:31 · Score: 1
  
  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 ;)
5. Re:thanks-- by garysears · 2003-09-29 06:32 · Score: 1
  
  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...
6. Re:thanks-- by garysears · 2003-09-29 06:49 · Score: 1
  
  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.
7. Re:thanks-- by Anonymous Coward · 2003-09-29 07:42 · Score: 0
  
  Sure, but pointing it out is pretty crass.
8. Re:thanks-- by pavon · 2003-09-29 08:26 · Score: 1
  
  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 this from time to time, lest we fall into the dark side :)
9. Re:thanks-- by pavon · 2003-09-29 08:32 · Score: 1
  
  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 :)
10. Re:thanks-- by Anonymous Coward · 2003-09-29 15:06 · Score: 0
  
  Oh, and now you're insulting the reviewer even further. I mean thanks-- isn't all that bad. After all, you're only decrementing the thanks value after passing it along. But you've gone one step worse. You only increment the thanks AFTER you give it. It's like saying "thanks, but the next person will get even more thanks than I gave you".
  
  If you really want to give a compliment, you should say ++thanks.
11. Re:thanks-- by Progman · 2003-09-30 01:19 · Score: 1
  
  Thanks, very nice of you.
  
  --Eric, co-author
damn...this guy beat me to it and copied my ID by Anonymous Coward · 2003-09-29 05:18 · Score: 0

Ref: Here's my amazon link anyway...
If you want this book by Sir+Haxalot · 2003-09-29 05:20 · Score: 0

It's right here

--
I have over 70 freaks, do you?
My $0.02 by Anonymous Coward · 2003-09-29 05:21 · Score: 0, Informative

mod_perl embeds the popular programming language Perl in the Apache web server, giving rise to a fast and powerful web programming environment. Practical mod_perl is the definitive book on how to use, optimize, and troubleshoot mod_perl. New mod_perl users will learn how to quickly and easily get mod_perl compiled and installed. But the primary purpose of this book is to show you how to take full advantage of mod_perl: how to make a mod_perl-enabled Web site as fast, flexible, and easily-maintainable as possible. The authors draw from their own personal experience in the field, as well as the combined experience of the mod_perl community, to present a rich and complete picture of how to set up and maintain a successful mod_perl site.

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.
1. Re:My $0.02 by Sir+Haxalot · 2003-09-29 05:23 · Score: 1, Troll
  
  The above review was stolen from the Amazon website.
  
  --
  I have over 70 freaks, do you?
2. Re:My $0.02 by Mortanius · 2003-09-29 05:56 · Score: 1
  
  Thanks for graciously saving us the bothersome task of going to oreilly.com and reading their review ourself.
how about you by Anonymous Coward · 2003-09-29 05:21 · Score: 0, Funny

code in C you fucking GNU hippies
1. Re:how about you by Anonymous Coward · 2003-09-29 05:51 · Score: 0
  
  C is a man's language that puts hair on your chest. Microsoft Java is for pansies.
what about just "Impractical Perl"? by Anonymous Coward · 2003-09-29 05:23 · Score: 0, Troll

I know this MUST exist, looking at the majority of Perl code I find. Someone tell me please, where I can find this book. I am interested in the whole Impractical Software series actually. I am particularly excited about "Impractical PHP Tools" in which I will be instructed upon how to bastardize a PHP project enough to make all the "modules" inherently unusable outside of the very limited scope the original scripter thought of. There are supposed to be tools on how to turn any well designed modular system into a hardcoded piece of overlapping and spaghetti crap. I even hear they wisely placed a section inside instructing the reader upon how to hide documentation for the API and module development and ensure a proper "voyage of discovery" for new users.
Next I think I will get the special publication of "Why I am better than you: Proper angst and attitude in self labled open source"
honestpuck sure does read a lot by Anonymous Coward · 2003-09-29 05:29 · Score: 0

mod_perl grep awk nerds >> who-cares.txt
1. Re:honestpuck sure does read a lot by Anonymous Coward · 2003-09-29 05:58 · Score: 0
  
  He reads the sample pages online and writes the same generic review for each and every book, the editors are just too fucking stupid to notice.
general note: what is it by kisrael · 2003-09-29 05:40 · Score: 3, Informative

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
1. Re:general note: what is it by garysears · 2003-09-29 06:19 · Score: 1
  
  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?
2. Re:general note: what is it by ajs · 2003-09-29 06:24 · Score: 5, Informative
  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.
3. Re:general note: what is it by CoughDropAddict · 2003-09-29 07:36 · Score: 1
  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 rewrites the authentication header to strip SOMEDOMAIN\. Here's the script I wrote to do this
  
  Authorize users by arbitrary criteria. I wrote an authorization handler that will allow users to DAV into any URL of the form /theirusername/*.
4. Re:general note: what is it by tzanger · 2003-09-29 08:02 · Score: 1
  
  What if you just want perl to run fast on Apache? That's what I'm using it for.
5. Re:general note: what is it by ajs · 2003-09-29 08:26 · Score: 1
  
  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 more complex that could take advantage of Perl's goodies, then great, but you probably want to look into something like HTML::Mason or perhaps one of the lighter weight tools that are layered on top of mod_perl, and make your code MUCH more maintainable, and allow you to avoid inventing wheels all over again.
  
  mod_perl's CGI handling is a nice patch for people who already had a base of CGI code and needed to make it persistant, but I think it's usually worth it to just take that code-base and re-implement it on top of something that already does some of the work for you.
6. Re:general note: what is it by Curly · 2003-09-30 04:26 · Score: 1
  
  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.
  The drawback is that the children can be large (e.g., 25MB), requiring you to do some engineering to accomodate a lot of children. (E.g., have a non-mod_perl front-end Apache server for non-mod_perl requests, or a Squid cache can help, or preload everything so most of the bloat is shared.)
I'd like to draw your attention to by Sir+Haxalot · 2003-09-29 05:45 · Score: 1, Informative

this, get it sorted please, mods.

--
I have over 70 freaks, do you?
Stas is the man by jslag · 2003-09-29 05:45 · Score: 3, Informative

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.
mod parent up man. it's good shit by Anonymous Coward · 2003-09-29 05:46 · Score: 0

*** don't read this ***
Maybe this is a stupid question... by henriksh · 2003-09-29 05:46 · Score: 1

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?
1. Re:Maybe this is a stupid question... by Green+Light · 2003-09-29 05:59 · Score: 1
  
  yes, yes, I think that perhaps it is...
  
  --
  "Send an Instant Karma to me" - Yes
2. Re:Maybe this is a stupid question... by garysears · 2003-09-29 06:24 · Score: 1
  
  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.
3. Re:Maybe this is a stupid question... by shaldannon · 2003-09-29 06:39 · Score: 1
  
  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 niche this book fills, and from reading the review, it sounds like it does that nicely.
  
  I don't work with mod_perl (although I have worked with Mason code that used mod_perl), so I can't justify buying the book right now, but I would like to take a peek at it sometime.
  
  By the by, if someone needs a Perl developer in the Raleigh area who has 2 years experience with Mason, Apache, and Verity and 3-4 years experience with Perl, let me know.
  
  --
  
  What is your Slash Rating?
For price comparisons.... by Anonymous Coward · 2003-09-29 05:46 · Score: 1, Informative

...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
1. Re:For price comparisons.... by justMichael · 2003-09-29 09:23 · Score: 1
  
  All Book Stores is a good place as well, although they don't list Bookpool which happens to be my preference for tech books and usually the least expensive.
  
  YMMV- I am in no way affiliated with either of those sites.
Is there anything in there... by realdpk · 2003-09-29 05:49 · Score: 1

...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 (the number one problem)?
1. Re:Is there anything in there... by consumer · 2003-09-29 05:54 · Score: 4, Informative
  
  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.
2. Re:Is there anything in there... by hondo77 · 2003-09-29 05:57 · Score: 1
  
  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.
  
  --
  I live ze unknown. I love ze unknown. I am ze unknown.
3. Re:Is there anything in there... by Anonymous Coward · 2003-09-29 06:15 · Score: 0
  
  Step one - only use Perl programmers who know how to code properly ;-) If the code is badly written and doesn't "use strict", then chances are it will leak memory. Because the code is persistant in memory, you need to ensure you write nice clean scripts.
  
  I've just finished two years of a national UK educational project for creating online e-learning material. The entire site is mod_perl, but has been carefully coded to try and minimise any possible memory leaks.
  
  The site is only running on a low spec'd Solaris box (about 160mHz I think, with a decent amount of memory), but it handled a huge amount of traffic this week as students were given their induction sessions using our site. The same number of hits on a standard CGI web server would have killed it in no time at all.
  
  The feedback I've got from users up and down the country was that the server was highly responsive, even when the usage peaked. Plus, the server logs show very little paging activity and very few periods of high CPU usage.
  
  If you're not seeing the same on your server, then it's not mod_perl's fault - you need to blame your developers for writing poor/sloppy code :-(
4. Re:Is there anything in there... by KMitchell · 2003-09-29 06:20 · Score: 3, Informative
  
  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.
5. Re:Is there anything in there... by ukpyr · 2003-09-29 06:27 · Score: 2, Informative
  
  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;
6. Re:Is there anything in there... by Anonymous Coward · 2003-09-29 06:59 · Score: 0
  
  Bro. Small apaches doing everything else then mod proxy to the big fat mod perl instances running in monter big apaches.
  
  I'm off my face on magic mushrooms but trust me it works.
7. Re:Is there anything in there... by RandomCoil · 2003-09-29 07:17 · Score: 0
  
  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... :)
8. Re:Is there anything in there... by Arrowhead · 2003-09-29 09:34 · Score: 1
  
  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.
9. Re:Is there anything in there... by xpatiate · 2003-09-29 12:59 · Score: 1
  
  indeed... there have been many conversations in our office about the need to kill the children when they get too fat, probably causing some raised eyebrows in passers-by...
  
  --
  (music + neurology) * fiction = feedback
10. Re:Is there anything in there... by Dom2 · 2003-09-30 00:33 · Score: 1
  
  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've set MaxClients quite low (much lower than the default of 150!).
  This sort of thing is well documented in most of the mod_perl literature. Tell you what, why don't you purchase the reviewed book and find out!
  -Dom
Re:Perl != Good by bill_mcgonigle · 2003-09-29 05:53 · Score: 2, Funny

Perl == Bad.

it's Perl ne 'Bad', duh.

--
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
ModPerl vs Php? by tjstork · 2003-09-29 05:56 · Score: 1

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?

--
This is my sig.
1. Re:ModPerl vs Php? by Anonymous Coward · 2003-09-29 06:00 · Score: 0, Flamebait
  
  ASP isn't simple and elegant? PHP is practically the same thing as ASP! Ugh.
  
  PHP is a bit more unwieldy than ASP because it resembles perl which, while once you get good at it is quite powerful, simply isn't very legible a lot of the time.
  
  and ASP.Net rocks because you can use any language you want... but of course, now that I've said something positive about Microsoft I'm doomed to be modded down by these faggots.
2. Re:ModPerl vs Php? by consumer · 2003-09-29 06:07 · Score: 2, Informative
  
  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.
3. Re:ModPerl vs Php? by hondo77 · 2003-09-29 06:19 · Score: 2, Interesting
  
  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 live ze unknown. I love ze unknown. I am ze unknown.
4. Re:ModPerl vs Php? by otis+wildflower · 2003-09-29 06:21 · Score: 1
  
  but of course, now that I've said something positive about Microsoft I'm doomed to be modded down by these faggots.
  
  No, you'll be modded down because IIS sucks donkey ballz in terms of stability and security, and because of the obvious flamebait.
  
  I suppose you _could_ run ASP in Apache, but for gods sake why?
  
  I have issues with PHP meself (method signature overloading please???) but I'd take it in a heartbeat over any M$ junk, if only because I'd need M$ junk to test, debug and deploy it...
5. Re:ModPerl vs Php? by Neil+Watson · 2003-09-29 06:29 · Score: 3, Informative
  
  Amazon also uses Mason. See here. Although, IIRC mod_perl is required for Mason.
  
  --
  UNIX/Linux Consulting
6. Re:ModPerl vs Php? by glwtta · 2003-09-29 07:30 · Score: 1
  
  I'm sorry, but if you spell mod_perl "ModPerl" you just didn't use to "love it."
  
  --
  sic transit gloria mundi
7. Re:ModPerl vs Php? by WWWWolf · 2003-09-29 10:53 · Score: 1
  
  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...).
No room for Mason? by madprof · 2003-09-29 06:02 · Score: 1

It would have been nice if they could have found room to cover HTML::Mason 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.
1. Re:No room for Mason? by Anonymous Coward · 2003-09-29 06:17 · Score: 0
  
  No problemo! Just buy O'Reilly's "Embedding Perl in HTML with Mason", or better still, read it for free online:
  
  http://www.masonbook.com/book/
2. Re:No room for Mason? by madprof · 2003-09-29 06:23 · Score: 1
  
  I have already read that - I was commenting on choice of systems to introduce readers to.
3. Re:No room for Mason? by Progman · 2003-09-30 01:22 · Score: 1
  
  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
4. Re:No room for Mason? by madprof · 2003-10-01 22:50 · Score: 1
  
  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.
I use both, all day every day by DrSkwid · 2003-09-29 06:13 · Score: 0, Flamebait

they are crud

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

--
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
1. Re:I use both, all day every day by Anonymous Coward · 2003-09-29 06:20 · Score: 0
  
  Really? They both told me that you're the cruddy one :-D Rumour has it that you prefer IIS
2. Re:I use both, all day every day by Fastball · 2003-09-29 08:07 · Score: 1
  
  If you want performance, rm -f /usr/local/etc/apache
  Funny. I've never seen Apache installed under /usr/local/etc/. You must be confused. Can I interest you in one of these?
3. Re:I use both, all day every day by DrSkwid · 2003-09-29 11:48 · Score: 0, Flamebait
  
  FreeBSD ports installs the config files there
  
  so, er, fuck you
  
  --
  There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
4. Re:I use both, all day every day by Fastball · 2003-09-29 14:19 · Score: 1
  
  And you're content to wipe out config files and leave Apache binaries to rot in /usr/local/bin.
  
  So, er, eat a dick.
Perl, and web security documentation by Anonymous Coward · 2003-09-29 06:14 · Score: 1, Informative

www.cgisecurity.com/lib/
Re:The Whigs by Anonymous Coward · 2003-09-29 06:29 · Score: 0

And now they're the Lib Dems.

BTW, fuck Slashdot. These "editors" could never get a professional writing job. Sycophantic pieces of talentless shit.
reading documentation for Perl? as if! by mrfoos · 2003-09-29 06:29 · Score: 1

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. ;)
Re:Perl != Good by mustangsal · 2003-09-29 06:53 · Score: 1

Now that's funny!

--
1+2+1+1 || 1+2+2+1
Re:Now listen here.... by Anonymous Coward · 2003-09-29 07:14 · Score: 0

it's a beautiful day!
Perl's for dilettantes! by Anonymous Coward · 2003-09-29 07:17 · Score: 0

You young whippersnappers think you know shit, what with you interweb and SQL databases!
If you REALLY want to write write-only code, you need to use APL!
Re:The Whigs by Anonymous Coward · 2003-09-29 07:23 · Score: 0

I thought whiggers drove around in riced up Honda Civics with coffeecan exhaust tips and listened to 50 cent with the volume cranked up so loud you could hear them inside you SUV. Oh, and they wear baggy pants and their ballcaps on backwords so you can easily identify them as idiots.
mod_perl 2 contents (lack of) by Lorphos · 2003-09-29 09:28 · Score: 1

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.
Re:The Whigs by Anonymous Coward · 2003-09-29 12:29 · Score: 0

Amasing. All those people that dont know one another and yet that idiotic culture makes its rounds all over the country, and beyond.
Good by Prax101 · 2003-09-29 23:23 · Score: 1

Good book, but for us noobies more examples are needed.
kris@maficstudios.com
sales@maficstudios.com
jobs@maficstudios.com
yawn .... by DrSkwid · 2003-09-30 00:09 · Score: 1

I tell you what, shut up

--
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Ha by Fastball · 2003-09-30 01:01 · Score: 1

Neener neener neener. You must carry out a sad existence to be so embittered. When was the last time you rubbed one off?
1. Re:Ha by DrSkwid · 2003-09-30 01:14 · Score: 1
  
  just now
  
  would you like the last word or can we call this pointless diatribe over?
  
  --
  There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
2. Re:Ha by Fastball · 2003-09-30 12:03 · Score: 1
  
  Over and out.