Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

mod_perl Developer's Cookbook

timothy posted about 12 years ago | from the boiling-over dept.

Perl 80

davorg writes "Over the last few years mod_perl has become a serious force in web development. If you're building a web site to run on an Apache server and you want to write the code in Perl, then you're going to want to install mod_perl on your server too as it's the best way to avoid many of the performance issues with traditional CGI. It's taken a while for publishers to wake up to the fact, however, and there haven't been many books in the shops. It looks like this will be the year that this changes. A number of mod_perl books are about to be published and this is the first." Read on below for Daveorg's thoughts on this one.

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.

cancel ×

80 comments

Sorry! There are no comments related to the filter you selected.

frist ps0t (-1, Flamebait)

Anonymous Coward | about 12 years ago | (#4281017)

perl sucks. get a real language to work with.

Yeah, stick it to the man!! Long live VBScript!!! (-1, Offtopic)

Anonymous Coward | about 12 years ago | (#4281109)

Not a really useful book (3, Insightful)

MrBoombasticfantasti (593721) | about 12 years ago | (#4281019)

It doesn't actually add much to the info already available at CPAN. Still nice to have it on the shelve.

Re:Not a really useful book (2)

thaigan (197773) | about 12 years ago | (#4281148)

Except that I can read it while on the train.

Re:Not a really useful book (1)

MrBoombasticfantasti (593721) | about 12 years ago | (#4281172)

It is in Cookbook style, and therefore not very suitable for reading while away from your computer. Unless you take a laptop, but then your point is moot. Anyway, I like to book, but there isn't much new stuff in it.

Re:Not a really useful book (2)

thaigan (197773) | about 12 years ago | (#4281209)

Maybe I'm the only one, but I like to read Cookbook style books even when I'm away from the computer.

Re:Not a really useful book (1)

MrBoombasticfantasti (593721) | about 12 years ago | (#4281647)

I'm sure you're not alone in this, but generally speaking the cookbook style is more useful with a computer at hand. To each his own. Enjoy!

Re:Not a really useful book (to you?) (5, Informative)

lindner (257395) | about 12 years ago | (#4281350)

It doesn't actually add much to the info already available at CPAN. Still nice to have it on the shelve.

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

Re:Not a really useful book (to you?) (1)

MrBoombasticfantasti (593721) | about 12 years ago | (#4281692)

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.

Re:Not a really useful book (to you?) (1)

d_i_r_t_y (156112) | more than 11 years ago | (#4287524)

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

Re:Not a really useful book (2)

consumer (9588) | about 12 years ago | (#4281368)

I disagree. It is better organized and more clearly presented than most of the on-line documentation, and it provides more examples. It also shows how to do things that are not discussed anywhere else, like automatically caching the output of a content handler. It's a very handy book to have.

Re:Not a really useful book (0)

Anonymous Coward | about 12 years ago | (#4283369)

actually, there is quite a bit of code that was both new and novel when the book was published. for instance...

the recipe for intercepting writes to the error_log [modperlcookbook.org]

an API for interfacing with Digest authentication [modperlcookbook.org]

using Apache::RegistryLoader as a PerlRestartHandler [modperlcookbook.org]

making XBitHack [modperlcookbook.org] actually useful on Win32

automatically transforming incoming UTF8 charset data [modperlcookbook.org]

making Apache API functions available outside of a running Apache server [modperlcookbook.org]

cleaning up stale Apache::DBI connections without killing the child process [modperlcookbook.org]

and more... useful stuff.

can it be? (-1)

Drunken Coward (574991) | about 12 years ago | (#4281020)

It can't possibly be two in a row, can it?

fsdafsa fs (-1, Offtopic)

Anonymous Coward | about 12 years ago | (#4281023)

blah fdsaf fa asd s fsda fsda fsda fasd asdf asdf s

Useless review (1)

vlag (552656) | about 12 years ago | (#4281029)

I appreciate the reviewers candor, but couldn't he have done a more thorough review instead of just focusing on some of the book???

Re:Useless review (1)

vlag (552656) | about 12 years ago | (#4281044)

What he really did was summarize the book, not review it. I agree with the popular view though. This is a decent book but doesn't add to much to existing literature on this subject. More dead trees.

Sad News, All-Star Gorilla, Patrick Ewing Retires (-1, Offtopic)

Anonymous Coward | about 12 years ago | (#4281047)

Ewing retires, accepts coaching job with Wizards [www.kose.ee]
Associated Press

NEW YORK -- As Patrick Ewing talked about his retirement, there was a softness in his eyes, a relaxed look replacing the glare he used while establishing himself as one of the 50 greatest players in NBA history.

Patrick Ewing
Patrick Ewing will go right from his official retirement as a player to the Wizards' bench as an assistant coach.

Then Ewing saw old pal Charles Oakley in the back of the room and his eyes danced. ''My hit man, Oak! We had some times, didn't we, Oak?'' Ewing shouted from the podium.

Indeed they did.

And for a fleeting moment Tuesday, Ewing was back under the basket with Oakley, the two battling for baskets and bounces, trying to put the New York Knicks over the top.

They never quite got there, but they had fun trying.

For 15 years, Ewing was the centerpiece of the Knicks, New York's go-to guy. There were two wrap-up seasons with Seattle and Orlando, footnotes to a career as one of the league's most dominant centers.

The 40-year-old Ewing finishes his NBA career with 24,815 points and 11,606 rebounds. He'll move on to become an assistant coach for Michael Jordan and the Washington Wizards.

The 11-time All-Star holds a number of Knicks records, including leading scorer (22.8 points) and leading rebounder (10.4). Most of the time, Oakley was right there with him.

''He came to work every day,'' Oakley said. ''He put a lot of effort into what he wanted to do, what he wanted to accomplish.''

Also attending Ewing's farewell news conference were ex-teammates Charlie Ward, Allan Houston, Herb Williams and Mark Jackson; coaches Mike Jarvis, Don Chaney and Jeff Van Gundy; and Miami's Alonzo Mourning, out for the season with the Miami Heat because of his kidney condition.

Ewing was asked how he wanted to be remembered.

''As a hard hat,'' he said. ''A hard nose. The work ethic I brought, I gave it 110 percent. I thought I had a great career. I have no regrets. I wouldn't trade it for anything. I enjoyed every minute.''

The NBA championship was the missing piece of the puzzle for the man who led Georgetown to three NCAA finals, including the 1984 title, before becoming the No. 1 pick in the first NBA lottery draft.

''I'm disappointed I never won a championship -- in the pros,'' Ewing said. ''We did the best we could to help the franchise win one. It didn't happen. That's life. You've got to move on.''

In 1994, Ewing led New York to a 3-2 lead over the Houston Rockets in the NBA Finals before losing in seven games. He said his greatest memory was converting a putback on a shot by John Starks that beat Indiana for the Eastern Conference title and put the Knicks in those finals.

Ewing was injured in 1999 when the team lost in the finals in five games to the San Antonio Spurs.

Now, he'll be an assistant coach with the Wizards, Jordan's team.

After general manager Wes Unseld signed him, Ewing was asked about the irony of working with Jordan, who often denied him his shot at an NBA title.

''Instead of needling me from afar, he'll be needling me in the same town. We'll be in the same organization,'' Ewing said.

Pat Riley, who coached Ewing and the Knicks to the finals in 1994, said: ''I'm sure that his next career in coaching will be just as successful as his playing career.''

For owner Abe Pollin, the signing of Ewing brings an important asset to the Wizards.

''It will be a unique opportunity for our players to be tutored by three of the 50 greatest players of all time -- Michael Jordan, Wes Unseld and now, Patrick Ewing,'' he said.

Ewing said he had thought hard about retiring, discussing it thoroughly with friends and family.

''It's still a hard decision,'' he said. ''It's still 50-50. Should I play? Should I retire? I felt I could still play.

''It's time to move on. It was a great ride.''

So what happens if sometime next season some NBA team decides it needs help in the middle? Is Ewing available?

He laughed at the question.

''A few teams called,'' he said. ''I made this decision anyway. Unless one of the Wizards goes down and they tell me, 'Put down the pad, we need you to go get some shots ...'''

Dave Checketts, longtime president of the Knicks, remembered Ewing's work ethic. In a game against Milwaukee, the center banged his knee and, with the Knicks comfortably in front, he went to the dressing room. Checketts came down to join him.

As the two men sat, talking basketball and families, the Bucks sliced the Knicks' lead to single digits. Ewing, watching on the dressing room television, took note of the situation, removed the ice from his knee and stood up.

'''Look,''' Checketts recalled him saying, '''I've enjoyed talking to you, but I've got to go.'''

''He pulled the sleeve over his knee, went back out to check into the game and we won it.''

mod_perl is not just "quicker CGI" (5, Informative)

ajs (35943) | about 12 years ago | (#4281054)

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.

Re:mod_perl is not just "quicker CGI" (1)

rplacd (123904) | about 12 years ago | (#4281078)

exactly how do you run interpreted perl code faster than compiled C code?

Re:mod_perl is not just "quicker CGI" (1)

eam (192101) | about 12 years ago | (#4281104)

I may be wrong, but I think he was saying that by caching the output to disk, additional requests are served faster than compiled C code could dynamically generate the page.

Of course, the binary could also cache the page...

Re:mod_perl is not just "quicker CGI" (-1, Offtopic)

rplacd (123904) | about 12 years ago | (#4281143)

ah, that would make sense.

Re:mod_perl is not just "quicker CGI" (3, Informative)

ajs (35943) | about 12 years ago | (#4281153)


Request 1: xyz.html

file not found
mod_perl intercept of 404 calls xyz.pl
xyz.pl writes xyz.html (e.g. from database)

Request 2: xyz.html

file exists
sendfile or tux used to fire file to socket


Even C cannot dynamically generate a file as fast as it can be read from disk. Granted, you could write the same plugin in C as you wrote in mod_perl (mod_perl uses the C API for apache after all), but it would be a lot more work, and all you would get is the performance boost on that first page generation, after that they perform the same.

This is the model used by at least one major content management system that uses a language that make Perl look zippy by comparison. They still compete because most page views are found on disk.

Of course, now you get to play the cache management game, but that's the right problem to have when serving lots of content.

Re:mod_perl is not just "quicker CGI" (3, Insightful)

cperciva (102828) | about 12 years ago | (#4281204)

Even C cannot dynamically generate a file as fast as it can be read from disk.

That depends upon what the file is, and how fast your disk system is. Many large scientific computations which, in the past, precomputed values and stored them to disk now recompute as necessary, simply because the recomputation is faster than a disk access.

You won't be able to regenerate a file as fast as it can be read from cache; but unless you have an infinite amount of cache memory, there are likely to be cases where you're better off to recompute and allow something else to be cached.

Re:mod_perl is not just "quicker CGI" (2)

ajs (35943) | about 12 years ago | (#4281292)

True, but only in the case of huge files that require no disk access to generate dynamically. Since most dynamic content on the Web requires a database....

C's sendfile can (when possible) perform a DMA transfer from the disk controler to the ethernet controler, which will beat the snot out of any relational database access.

Re:mod_perl is not just "quicker CGI" (2)

cperciva (102828) | about 12 years ago | (#4281489)

True, but only in the case of huge files that require no disk access to generate dynamically.

Except that the database entries used are more likely to be reused for other requests -- so if the output could be cached, the database certainly would be.

Obviously, in some cases it is better to precompute entire pages; but it is really something which has to be determined on a case-by-case basis.

Re:mod_perl is not just "quicker CGI" (2)

ajs (35943) | about 12 years ago | (#4281627)

Except that the database entries used are more likely to be reused for other requests -- so if the output could be cached, the database certainly would be.

I'm going to explain why this is wrong, but first let me explain that you're in some very good company in having made this assumption. I and just about everyone I know who've seen a good caching content management system in use have been stunned by the simplicity and correctness of the solution. In the case of Vignette (the one I'm most familliar with), I was also stunned that such slipshod software written in a language that couldn't even do lexical scoping (TCL) was doing this one thing so well :-)

Ok, on to the technical. Yes, you can cache your database in memory (Oracle lets you cache gigs and gigs in RAM), but that buys you a lot less than you would think.

You still have to execute millions upon millions of instructions just to generate the simplest page. When an HTML file is on disk, apache just calls sendfile(2), which copies the file from disk to socket with no userland code in between. Trust me when I say that this is so much more efficient that it's not even worth the comparison.

Re:mod_perl is not just "quicker CGI" (2)

consumer (9588) | about 12 years ago | (#4281805)

Caching data, as opposed to just caching generated HTML, allows you to reuse that data in other pages, some of which can't be cached. For example, I worked on an application where we would cache data from a product catalog and use that data in the browsing pages, the shopping cart, the gift registry, etc.

A good system will allow for caching of both data and generated HTML.

Re:mod_perl is not just "quicker CGI" (2)

cperciva (102828) | about 12 years ago | (#4282928)

You still have to execute millions upon millions of instructions just to generate the simplest page

Only if you write crappy code, or you have extremely complicated pages. A few hundred thousand cycles is reasonable for well written code generating a web page from cached data.

Re:mod_perl is not just "quicker CGI" (2)

ajs (35943) | about 12 years ago | (#4283714)

Only if you write crappy code

Nope

or you have extremely complicated pages.

Nope

A few hundred thousand cycles is reasonable for well written code generating a web page from cached data.

Most assuredly nope!

Sure, I too can come up with a home page for peeling paint that I can generate with a six-line C program. But, even moderate complexity would run you aground.

How are you caching data? How are you locking/cleaning/managing/clearing that cache? Your page generation will have to be in bed with that to some extent in order to determine if a new page request invalidates some or all of the cached data that it touches. Then, you're going to have the small matter of how you share this cached data. Is it in a simple database (e.g. Berkeley DB) or a second-tier relational database or do you try to manage a live, shared memory cache. Cache consistency management on that's going to get ugly fast!

Now, you start dealing with protocol management, HEAD vs GET vs POST requests, parsing POST bodies. URL-encoding, cookie access, security, etc, etc.

"Well written code" as defined by number of cycles consumed usually means that many of these needs are handled in a one-off way that does not take into account the mountain of special-cases that makes up what we call the World Wide Web.

Instead I suggest you spend all of that premature optmization energy on writing a good cache management system that can mix and match static HTML cache with dynamically generated pages on the fly. That would benefit everyone, not just one Web page.

Re:mod_perl is not just "quicker CGI" (1)

cperciva (102828) | about 12 years ago | (#4283936)

How are you caching data? How are you locking/cleaning/managing/clearing that cache?

I'm not. The operating system is.

Re:mod_perl is not just "quicker CGI" (1)

ajs (35943) | about 12 years ago | (#4286433)

We're talking past each other, so I guess it's time to stop. Suffice to say that if you can write the better content management system, I'll run it....

Re:mod_perl is not just "quicker CGI" (0)

Anonymous Coward | about 12 years ago | (#4281404)

The formula here is: compute time + write time(stdout or file) read time(disk access). That is all the poster was saying. Your right you can't cache everything every time, but caching error pages on a web page are a far cry from calculating large arrays. A good algorithm can crunch numbers alot faster than it can read and write them to disk. But you trade off memory, as long as you have enough memory you can continue, but run out of memory and you start paging to disk, gaining nothing. The biggest gain by far in using mod_perl is the fact that you don't call the interpreter everytime loading it from disk and are creating threads which use alot less memory resources.

Re:mod_perl is not just "quicker CGI" (0)

Anonymous Coward | about 12 years ago | (#4281265)

Thats just plain ignorant ajs. It would be more accurate to say it is easier for people who may not have a great understanding of either language to get it up and running faster using mod_perl than they could using a C compiled binary. But to make such a blanket statement is simply wrong. Even though there may be some trueth associated with your thought it doesn't come across in your post.

Re:mod_perl is not just "quicker CGI" (1)

scottj (7200) | about 12 years ago | (#4281663)

This is the model used by at least one major content management system that uses a language that make Perl look zippy by comparison. They still compete because most page views are found on disk.

They compete with other commercial software. But at US$500,000 for licensing (average), they're nowhere near competing with mod_perl.

Re:mod_perl is not just "quicker CGI" (2, Informative)

WWWWolf (2428) | about 12 years ago | (#4281412)

However, it's much more than a CGI accelerator. It provides hooks into all of the stages of an apache transation.

Yeah, I found it extremely appealing for two reasons: First, I hate writing configuration file readers - and with mod_perl, $request->dir_config('whatever'); to read stuff that is set with PerlSetVar in .htaccess or server conf. The second reason: Logging with various debug levels. Easy with Apache::Log.

Re:mod_perl is not just "quicker CGI" (3, Insightful)

Glorat (414139) | about 12 years ago | (#4281477)

Actually, one of the barriers to mod_perl use is that mod_perl by default does *not* provide transparent wrapping of CGI programs. It can be made to do so using PerlRun modules but I think it's just a case that a documentation needs to be more prominent about this fact that vanilla Apache::Registry scripts behave significantly different from CGI. Perhaps the documentation should advertise more the PerlRun modules (etc) that do give transparent CGI wrapping. I like many others have fallen into the trap of just blindly switching a script from CGI to mod_perl and bitten by many of the (documented) issues if you bother to RTFM which of course I didn't at first =)

Now that I know mod_perl indepth, the parent is correct in the immense flexibility of mod_perl with its ability to directly interface with Apache. Something you won't be able to do ever with CGI or even PHP.

And about You can write whole content management systems using mod_perl, and in fact many have. Of course the CMS running here at Slashdot is powered by Slashcode [slashcode.com] which runs under Apache/mod_perl.

Re:mod_perl is not just "quicker CGI" (3, Insightful)

gorilla (36491) | about 12 years ago | (#4281556)

An example of one of these content management systems would be mason, http://www.masonhq.com [masonhq.com] , and mason apps such as Fuse CMS [autistici.org] and Bricolage [thepirtgroup.com] . I find Mason to be just as powerful as multi-thousand dollar applications such as StoryServer [vignette.com]

C: A Dead Language? (-1, Offtopic)

Anonymous Coward | about 12 years ago | (#4281059)

Gentlemen, the time has come for a serious discussion on whether or not to continue using C for serious programming projects. As I will explain, I feel that C needs to be retired, much the same way that Fortran, Cobol and Perl have been. Furthermore, allow me to be so bold as to suggest a superior replacement to this outdated language. [goatse.cx]

To give you a little background on this subject, I was recently asked to develop a client/server project on a Unix platform for a Fortune 500 company. While I've never coded in C before I have coded in VB for fifteen years, and in Java for over ten, I was stunned to see how poorly C fared compared to these two, more low-level languages.

C's biggest difficulty, as we all know, is the fact that it is by far one of the slowest languages in existance, especially when compared to more modern languages such as Java and C#. Although the reasons for this are varied, the main reasons seems to be the way C requires a programmer to laboriously work with chunks of memory.

Requiring a programmer to manipulate blocks of memory is a tedious way to program. This was satisfactory back in the early days of coding, but then again, so were punchcards. By using what are called "pointers" a C programmer is basically requiring the computer to do three sets of work rather than one. The first time requires the computer to duplicate whatever is stored in the memory space "pointed to" by the pointer. The second time requires it to perform the needed operation on this space. Finally the computer must delete the duplicate set and set the values of the original accordingly.

Clearly this is a horrendous use of resources and the chief reason why C is so slow. When one looks at a more modern (and a more serious) programming language like Java, C# or - even better - Visual Basic that lacks such archaic coding styles, one will also note a serious speed increase over C.

So what does this mean for the programming community? I think clearly that C needs to be abandonded. There are two candidates that would be a suitable replacement for it. Those are Java and C#.

Having programmed in both for many years, I believe that C# has the edge. Not only is it slightly faster than Java its also much easier to code in. I found C to be confusing, frightening and intimidating with its non-GUI-based coding style. Furthermore, I like to see the source code of the projects I work with. Java's source seems to be under the monopolistic thumb of Sun much the way that GCC is obscured from us by the marketing people at the FSF. Microsoft's "shared source" under which C# is released definately seems to be the most fair and reasonable of all the licenses in existance, with none of the harsh restrictions of the BSD license. It also lacks the GPL's requirement that anything coded with its tools becomes property of the FSF.

I hope to see a switch from C/C++ to C# very soon. I've already spoken with various luminaries in the C coding world and most are eager to begin to transition. Having just gotten off the phone with Mr. Alan Cox, I can say that he is quite thrilled with the speed increases that will occur when the Linux kernel is completely rewritten in C#. Richard Stallman plans to support this, and hopes that the great Swede himself, Linus Torvalds, won't object to renaming Linux to C#/Linux. Although not a C coder himself, I'm told that Slashdot's very own Admiral Taco will support this on his web site. Finally, Dennis Ritchie is excited about the switch!

Thank you for your time. Happy coding.

Perl security papers (0)

Anonymous Coward | about 12 years ago | (#4281062)

www.cgisecurity.com/lib [cgisecurity.com]

website support (4, Informative)

Anonymous Coward | about 12 years ago | (#4281106)

we (the authors) support a companion website where you can find a number of useful items, such as all the code [modperlcookbook.org] from the book (to save your fingers) and a full-text search engine [modperlcookbook.org] (to supplement the index).

http://www.modperlcookbook.org/ [modperlcookbook.org]

enjoy

Re:website support (0)

Anonymous Coward | about 12 years ago | (#4281389)

Hmmm....almost-fp from the publisher! And I'm sure that they had absolutely nothing to do with the 'review.'

Re:website support (1)

davorg (249071) | about 12 years ago | (#4281419)

Not sure what you're trying to imply here. I have nothing at all to do with the publisher.

Re:website support (1)

FIGJAM (29275) | about 12 years ago | (#4285555)

Thats funny. You're saying author posted a review to /. and reloads the page repeatively as fast as he can for a few days until /. makes it public with the specific intention of trying to get first post, or at the very least, to post the information in the parent of this thread. puhleez

mod_perl slow, php good (-1, Offtopic)

destiney (149922) | about 12 years ago | (#4281111)


mod_perl is so slow, I heard the U.S. Postal Service wants to use it.

Re:mod_perl slow, php good (3, Informative)

consumer (9588) | about 12 years ago | (#4281216)

PHP is fine, but it's not as fast as mod_perl [chamas.com] .

Re:mod_perl slow, php good (1)

Chris Shiflett (607251) | about 12 years ago | (#4282575)

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.

Re:mod_perl slow, php good (0)

Anonymous Coward | about 12 years ago | (#4285797)

PHP has a small edge in database queries...

A small edge in what way? And do you have any benchmarks if it is performance wise?

Re:mod_perl slow, php good (1)

Chris Shiflett (607251) | about 12 years ago | (#4286706)

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.

Re:mod_perl slow, php good (1)

szap (201293) | about 12 years ago | (#4286490)

PHP has a small edge in database queries
As compared to mod_perl? Unlikely. The syntax is slightly different, but they all look similar, and would have similar performance boost. PHP slightly more popular for database queries, at least as "advertise" and hence your assumption of the edge. It's only perceived as having that extra edge.

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

<emit src='sq' query="select user,passwd from passwd">
User: &_.user; Password: &_.passwd; <br />
</emit>
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).

Re:mod_perl slow, php good (0)

Anonymous Coward | about 12 years ago | (#4281231)

PHP is so gay it's endorsed by Richard Simmons.

Re:mod_perl slow, php good (-1, Offtopic)

Anonymous Coward | about 12 years ago | (#4281248)

Surely you mean Richard Stallman?

To hell with the book. (-1, Offtopic)

Anonymous Coward | about 12 years ago | (#4281123)

Geoff Young is one of the sexiest men on the planet.

This book sucks (-1, Troll)

Anonymous Coward | about 12 years ago | (#4281169)

No pictures!

good book (-1, Troll)

Anonymous Coward | about 12 years ago | (#4281299)

I am a systems programmer for a popular website... the one you're reading write now! Anyhow, this is a good book. If you noticed SLASH hasn't been going down so much lately, it's because this book helped me get the mod_perl settings fixed up. Now if only O'Reilly would publish a book on the mysterious step 2 (2. ???) ...

CmdrTaco

It's taken a while for publishers to wake up to... (3, Informative)

pizza_milkshake (580452) | about 12 years ago | (#4281380)

it's taken /. a while as well; this book was published in January [amazon.com]

Re:It's taken a while for publishers to wake up to (3, Funny)

lindner (257395) | about 12 years ago | (#4281414)

As one of the authors it's been difficult to wait for this book to get more widespread exposure. One reason might be because it is published by SAMS. I suspect if there was a cute O'Reilly animal on the cover we'd be much more widespread at this point. Who knows, maybe we should stuck with the (unfounded) SAMS stereotype and named the book mod_perl unleashed in 21 days for dummies. Nah..

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 [modperlcookbook.org] .

Re:It's taken a while for publishers to wake up to (2, Informative)

davorg (249071) | about 12 years ago | (#4281507)

It's partly my fault. I got my review copy in June :-/

Not mod_perl 2.0 (2)

PineHall (206441) | about 12 years ago | (#4281618)

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.

Re:Not mod_perl 2.0 (2, Interesting)

lindner (257395) | about 12 years ago | (#4281656)

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.


Funny thing. We were worried that mod_perl 2.0 would steal our thunder. It's now september 2002 and we still don't have the official release.


Apache 1.3 and mod_perl 1.x will be around for a long time though. Especially on all those production servers that don't get the latest greatest software, only the boring reliable stuff...

A very useful book (2, Interesting)

barries (15577) | about 12 years ago | (#4281763)

Apache and mod_perl are incredibly powerful but complex systems; it's very difficultfor any one person, to keep all of the details and possible approaches to all of the things you can do with them in my^Wtheir head.

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

About to be published? I HAVE this book already. (0)

Anonymous Coward | about 12 years ago | (#4281794)

I picked this book up in B & N at least 2 months ago.

First Mod_perl book? Not quite (0)

Anonymous Coward | about 12 years ago | (#4281797)

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

Re:First Mod_perl book? Not quite (0)

Anonymous Coward | about 12 years ago | (#4282231)

The first mod perl book?

I think he meant the first of those books to come out this year, with Practical mod_perl [amazon.com] 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.

mod_perl has lots of problems (0)

Anonymous Coward | about 12 years ago | (#4282338)

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.

Re:mod_perl has lots of problems (0)

Anonymous Coward | about 12 years ago | (#4282847)

I agree that it's quite a memory hog, but you can sort of get around the "dirty" memory thing by setting a lower value for MaxRequests in your httpd.conf (yeah, it's not an ideal solution, since it sort of defeats the purpose of mod_perl in a way). I think the problem is that Perl 5 doesn't ever deallocate memory (although it does reuse any memory it already has). Hopefully they'll fix that in Perl 6...
As far as the vhosting stuff goes, I consider the biggest problem to be the fact that suexec doesn't work with mod_perl. mod_perl is great for dedicated sites, because it gives you tons of power (you can really do anything!) but for the same reason it's too hard to restrict users.

I'd like to use mod_perl but... (1)

stu42j (304634) | about 12 years ago | (#4282434)

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?

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. html [perl.com]

Re:I'd like to use mod_perl but... (2, Informative)

Anonymous Coward | about 12 years ago | (#4282859)

I don't think so. Mod_perl gets its hooks so much deeper into Apache than CGI does, that it's hard to share.

One problem is that a bad mod_perl program can bring down the server. A bad CGI program can't since by definition it's forking a new process to run, so all it can do is crash its own forked process.

Another issue is that in order to load new or modified mod_perl scripts, you need the privileges of the process running the server.
No way you can do that in a virtual hosting environment, unless you have a death wish.

In order to install a mod_perl script you also have to be able to edit the apache config file. Typically (for good reasons) a file writable only by root.

Another issue is that the apache processes running keep all the mod_perl programs in memory. If there were ten different mod_perl-enabled "web sites" run by the same apache server on the same box, that could get really inefficient.

More I think about it, the only way this could work is if each mod_perl virtual host has its own apache server instance, with full ownership of its own config file and privileges to bring it down and restart it.

You would need some kind of gateway server answering all requests coming in to port 80 and redirecting them to a different port depending on the request's URL; each mod_perl virtual host would have its own port number which the gateway server would redirect to.
This sort of internal redirect is often used now running a server without mod_perl to handle static requests, and a mod_perl-enabled server to handle dynamic requests on the same box.

-->So I have changed my off-the-cuff conclusion. You could do this all on one box, but it would be complicated, and a fundamentally different model than shared hosting with CGI only. And I'm not sure any hosting company is doing it. Nor am I sure that there aren't some bad security or performance implications I haven't thought of.

Just get DSL and start messing around running mod_perl on your own computer. If it's a low-volume or self-instructional site that should be quite adequate.

a bit late?? (0)

Anonymous Coward | about 12 years ago | (#4282709)

no offense to the authors of this fine book, but isn't it about - oh i dont know - 3 years late???

Paul Lindner is my hero.. (0)

Anonymous Coward | about 12 years ago | (#4283645)

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

Use PHP - faster, easier, more efficient (1)

bitpusherdotorg (544243) | about 12 years ago | (#4283727)

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!

Re:Use PHP - faster, easier, more efficient (0)

Anonymous Coward | about 12 years ago | (#4283870)

Yeah maybe for newbies it's easier to learn PHP, but I've been coding in Perl for over 3 years, and I read just about anyone's code (unless they obfuscate it on purpose anyway). Perl's not as difficult to read as everyone says IMO.

Re:Use PHP - faster, easier, more efficient (2)

unicron (20286) | about 12 years ago | (#4283879)

Maybe obfusgated(sp?) code. My perl looks just as good as my C/C++. I've never had a problem reading the perl of others, either, provided it was formatted and commented with just a little care.

Re:Use PHP - faster, easier, more efficient (2, Insightful)

bitpusherdotorg (544243) | about 12 years ago | (#4285047)

True, Perl doesn't have to be messy. It's all a matter of coding style. If you are a considerate developer, you will write clean, easy to read code that's replete with useful comments.
Unfortunately, there are people who want to write messy code out there, and I'll be damned if I have to maintain it!
Thanks for the point - clarity of code is a matter of style, but certainly the choice of language helps as well.

Re:Use PHP - faster, easier, more efficient (0)

Anonymous Coward | more than 11 years ago | (#4294965)

PHP is crap. It consumes memory like the beast it is and is also inefficient. I don't know who told you it's efficient but you're wrong. Perl is a programming language, not a web scripting language so you can't compare the 2. Perl is a better league and will always be superior. You obviously are an amateur to be speaking such words.

Re:Use PHP - faster, easier, more efficient (0)

Anonymous Coward | more than 11 years ago | (#4310009)

I use php frequently to fuck my women, which is more than I can say for you you fucking faggot. Go jerk off on your keyboard.

Re:Use PHP - faster, easier, more efficient (1)

Doppler00 (534739) | about 12 years ago | (#4284528)

Another powerful solution is Java Servlet Pages. With JSP you can combine HTML and java code together in one file. It's also likely to be faster than Python because it doesn't need to interpret each line of code before executing it.

Re:Use PHP - faster, easier, more efficient (0)

Anonymous Coward | about 12 years ago | (#4285029)

Your points are valid. However, sometimes policy is set by management and you are left with the tools which have been apporved. It is not as though each developer has complete control of her environment.

Re:Use PHP - faster, easier, more efficient (0)

Anonymous Coward | more than 11 years ago | (#4289518)

In my experience, I have found other peoples PHP code to be much harder to grok. Once your application gets moderately complex with PHP, you just get a giant lump of include files, and a whole bunch of HTML mixed in with your code (I used PHP extensively back in the v2.0-3.0 days).

What gives perl a bad name is the developers who write webapps with giant if else statements, and try to do as much as possible on 1 line thinking it will be faster (I used to be one many years ago). But if you use a clean OO structure for your code, separate your HTML from the code, and throw in the odd comment, any beginner programmer can read your code...

For me you just can't beat perl with a good template engine (like HTML::Template or Template Toolkit), and a nice DBMS behind it (PostgreSQL will do for 97.64% of apps out there). And running it on Apache with mod_perl just makes it that much more powerful.

You can write garbage code in just about any language. But if you organize things coherently, it can be as easy as reading a book.

Excellent (1)

DaRobin (57103) | more than 11 years ago | (#4287390)


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.


Registry? (1)

stonetemple (97639) | more than 11 years ago | (#4287448)

PerlRun is the component that allows CGI to be run without modification, not Registry.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>