Apache DevCenter
oreilly.comSafari Books Online.Conferences.


Apache Cookbook

A Day in the Life of #Apache
To Use Apache 1.3 or 2.0? That Is the Question

by Rich Bowen, coauthor of Apache Cookbook

Editor's note: Rich Bowen is back this week with yet another column based on his conversations on the IRC channel #apache. If you have an Apache question, you can find him on the web at www.drbacchus.com/journal, or on #apache (his handle on the IRC channel is DrBacchus), where he admits he spend spends entirely too much time. (And if you've missed any of his previous columns, a quick click on his name in the byline above will provide links to his previous six installments.) Enjoy.

#apache is an IRC channel that runs on the irc.freenode.net IRC network. To join this channel, you need to install an IRC client (XChat, MIRC, and bitchx are popular clients) and enter the following commands:

/join #apache

Day Seven

This month we're going to try to answer a question that comes up at least once a day, but which doesn't have one clear answer.

<rhythms> Should I use Apache 1.3 or 2.0?
<DrBacchus> Yes, you should.
<rhythms> Which one?
<fajita> It depends.
<rhythms> fajita: You're not being very helpful.
<fajita> Sorry ...

The thing is, it's not a simple either/or question. If you really want the short form, then the answer is that you should use Apache 2. It's better in every way.

Unfortunately, that answer comes with a few caveats, although fewer caveats than it did, say, a year ago. So let's take this in a couple different parts. First, there's the question of why you should use Apache 2, and next, there's the question of when you shouldn't.

<rhythms> What's better about apache 2?
<fajita> MPM, APR, filter chains, better authentication, more active development, ssl included, other cool modules included.

Yep, there's a lot to like about 2.0, and I won't do all of these things justice in this article, but I'll try to give you the high-level overview of each of these cool things.

<rhythms> MPM?
<fajita> MPM is http://httpd.apache.org/docs-2.0/mpm.html or Multi-Processing Modules

On Apache 1.3, Apache runs in what is called a prefork model. There's one Apache parent process, and several child processes, each of which can answer incoming HTTP requests. Lots of people like the prefork model, but some people want choices. Choices are good. So, in Apache 2, you have choices. These choices are called MPMs, because they represent different models of multi-processing.

If you like prefork, then use the prefork MPM. There's also worker, which is threaded. And there are a variety of other ones, including ones that are specifically for non-Unix operating systems, such as mpm_winnt and mpm_netware for Netware.

On most Unixes, the worker MPM results in considerable performance enhancements over the prefork MPM, and it results in much greater scalability, since threads are a lot cheaper (less memory and CPU to create and run) than forked processes.

<rhythms> What's APR?
<fajita> I think APR is Apache Portable Runtime or http://apr.apache.org/

Related Reading

Apache Cookbook
By Ken Coar, Rich Bowen

APR is a little less easy to explain without getting into a lot of gory details. The simple form is that it provides an interface to platform-specific things, so that code can be written once, rather than written again for each operating system. You can read a lot more about APR at the URL that fajita gave above.

What's next?

<rhythms> And filter chains?
<fajita> The term "Filter chains" refers to the ability to string multiple filters (http://httpd.apache.org/docs-2.0/filter.html) together. Like running a CGI program and then running the output through SSI, and then through DEFLATE, for example.

In Apache 1.3, you have one shot at creating content. You could, for example, use a CGI program, or perhaps a Server-Side Include page, but not both at the same time. Filter chains give you the ability to do both, or chain together any number of actions. This gives you a great deal more flexibility in creating content. It also is more in line with the Unix mindset. It's sort of like a piped command, such as ps ax | grep http.

In fact, mod_ext_filter lets you pipe web server output through arbitrary Unix commands, such as sed, to modify the content on its way out to the user. See some of the examples in the documentation.

The next few points that fajita makes are less quantifiable, I suppose.

The authentication/authorization model that is used in Apache 2.1 is much better thought out, leading to a rash of great new auth modules, such as mod_authn_dbi which lets you authenticate against basically any data source. And the auth model lets you pick whether you want this to be Basic or Digest auth, whereas in Apache 1.3 your choice of auth module automatically locks you into a particular auth protocol. Note that this new stuff is in 2.1, not in 2.0. 2.1 is the development branch of the 2.x code tree, which will eventually be released as 2.2 when it's ready. So this, technically, isn't a selling point for 2.0, but is something to look forward to in the future.

Most of the active Apache developers work on Apache 2.0. This means that, increasingly as time goes on, Apache 2.0 is likely to be the better product by greater margins. I expect that 1.3 will still be maintained for a long, long time. And there will always be security patches available for 1.3, as long as anyone is using it.

Apache 2.0 comes with a number of shiny new modules, such as mod_dav and mod_deflate. But perhaps most importantly, Apache 2.0 comes with mod_ssl. The U.S. government has lifted the most draconian of the anti-encryption legislation, allowing us to do that. So you no longer have to undergo the painful process of adding mod_ssl to Apache.

All of us leads this to the other question:

<rhythms> What sucks about Apache 2?
<fajita> Some reported problems with php and threading. mod_perl not out of beta yet. Not all third-party modules are available. Bad press leads to lots of misinformed morons saying stupid things about how Apache 2 is not ready for prime time.

The summary here is that not all of the modules that you want to use work on Apache 2.0 yet. The most notable of these are PHP and mod_perl. However, even here, the stories that you are likely to hear tend to be worse than the reality. Long ago, when PHP and mod_perl simply didn't work on Apache 2.0, that story got out into the wild. Now that it's no longer true, it is still very hard to kill the story that everyone knows to be fact. This is deeply annoying, and something that we'll have to grow out of over time.

There are reportedly some PHP things that are not thread-safe. If you happen to encounter one of these, then don't use a threaded MPM. That is, if you need one of those things, then use the worker MPM. Problem solved. Also, with the advent of PHP 5, which should be released any moment now, even the PHP folks are willing to say that it works on Apache 2.

And mod_perl? Well, officially, it's still beta. Here, again, there's a similar situation. mod_perl works great on Apache 2.0, but there are a lot of mod_perl handlers that don't work on Apache 2.0. This is unfortunate. A lot of the authors of those handlers don't particularly care, so we don't see those being migrated to 2.0 in a great hurry. If you need one of these handlers to work on 2.0, then send the author email, or, better yet, send code patches.

So ... have I answered the question? Which one should you use? I suspect that my bias is pretty clear, but it's not a simple answer for everyone. You need to consider the options, figure out what, if anything, you stand to gain (or lose) by moving to Apache 2.0, and make the decision that makes the most sense for you.

See you on #apache.

Check back here next month to see how Rich helps to resolve yet another common Apache dilemma.

Rich Bowen is a member of the Apache Software Foundation, working primarily on the documentation for the Apache Web Server. DrBacchus, Rich's handle on IRC, can be found on the web at www.drbacchus.com/journal.

In November 2003, O'Reilly & Associates released Apache Cookbook.

Return to the Apache DevCenter.

Sponsored by: