Apache 2: Improvements May Be Obvious, but Upgrade Choices Aren't

Friday Nov 8th 2002 by Carla Schroder

With Apache version 2 out and about, you might be confronting the question of an upgrade. Carla Schroder discusses why despite all the improvements, in some cases it makes sense to wait a bit and let the dust settle.

Apache 2.0 is a major rewrite of what is often referred to as "the best http server on the planet." As the Apache team modestly states in the release notes: "Apache is the most popular web server in the known universe; over half of the servers on the Internet are running Apache or one of its variants."

A few highlights in the new, improved Apache:

  • Apache Portable Runtime library
  • Content filtering
  • Improved performance for non-Unix platforms
  • Hybrid thread/process modes for speed and greater scalability
  • MPM: Multiprocessing modules
  • Better internationalization

Adding multithreading to Unix versions means a nice performance boost. In a sense, threads are lightweight processes. (Multithreading was already present for Windows and other platforms in the previous version.) Threads are now more efficient; processes are more stable. Processes are rugged individualists, consuming their separate shares of system resources. One process can create many threads, all sharing the same memory space.

Version 2.0 combines threads and processes, in fact an ace administrator can tweak various combinations for best performance. This is done with multiprocessing modules (MPM). These are selected and compiled into the server at configuration. Some MPMs also have configurable runtime options. Unix platforms have three MPM options:

  • Prefork: The 1.3 model. Single parent process spawns child processes to handle requests. Spare children are kept sitting around just in case. Excess children are killed off after a prescribed length of time. (This is what the docs say. Really.) This is the familiar old way of doing things, and it permits using thread-unsafe libraries.

  • Worker: Hybrid multiprocess and multithreads. Each process has a fixed number of threads, Apache adjusts the number of processes to meet the workload. More efficient and scalable, the one downside is if one thread segfaults, the entire process dies, taking all its threads with it. Because threads share memory space, programs must be written specifically to be "thread-safe."

  • PerChild: A fixed number of processes spawn varying numbers of threads. This is the most scalable option. It is also the trickiest -- you can imagine the consequences of one process dying when it is controlling a very large number of threads. Putting thousands of threads each on two processes is possible but probably unwise.

    PerChild has another interesting capability: configuring the user ID for various processes and virtual hosts. This presents possibilities in delegating administration chores with limited permissions.

To see what modules are installed, run ./httpd -l
./configure --help shows all configuration options.

The Apache Portable Runtime library permits employing the native API of the host operating system, while preserving a common core code base. Again, improved performance and bug fixes will apply to all platforms at once.

To Upgrade or Not to Upgrade?

The release announcement states "We consider this release to be the best version of Apache available and encourage users of all prior versions to upgrade." This is for version 2.0.43, the current release. The Apache Software Foundation has powered its own site on 2.0 since December 2000.

It's not quite that simple. Apache is highly extensible and customizable via the addition of modules; modules come from third-party sources, as well as the core modules that come with Apache. There is little-to-no backward compatibility for modules developed for older versions; they must be recompiled for the version of Apache that the user is running. An IT manager at a local ISP said "the biggest problem that we (and many others) have with deploying it everywhere is that the API hasn't yet stabilized, so modules, such as PHP, have to be recompiled and often slightly modified to get them to work every time Apache issues a new release. This is a pain as we often have to wait for days or weeks before all of modules that we may want to use have instructions on what to modify."

The development team is aware of this, and is planning to develop two code branches: one stable and one development. From the Apache developer's list: "We hope to start a stable branch of Apache 2 in the near future with the aim of keeping the API stable enough to encourage 3rd party modules authors to begin supporting Apache 2. If you need to use mod_perl, mod_php, etc. and you are not comfortable with compiling and possibly modifying the source code of these modules yourself, you better stay away from 2.0 for now."

I love programmers -- they think modifying source code is so easy! And it is, if you have the ability, or personnel, to do it. Having the source code means being able to tweak it exactly to suit your needs. The Apache developer's list is a treasure trove of information, and it is archived online. Please respect the developers' time and hard work, and do not vex them with foolish questions. Search the archives before posting any questions.

So Then, I Shouldn't Upgrade?
The most common answer to the upgrade question was "If it ain't broke, don't fix it." Apache 1.3 is a great program, no doubt about it. The ASF should be proud.

Ed Sawicki of Alcpress.com summed it up best: "For me, Apache 2.0 represents the future. There are numerous improvements in 2.0 that I like but aren't compelling - yet. These include:

"Threading -- for me this is a performance/scalability issue. I can choose from the classic Apache pre-forking parent/child process model and the new threads-based models.

"Multiprotocol support -- this new feature means that Apache can be the platform for other protocols besides HTTP. It can go beyond being thought of as a Web server. Apache can become a communications server supporting various protocols. This is a future capability because there are no other protocols yet besides the simple TCP echo protocol that was probably developed as a proof of concept.

"Filtering -- Ahhh, this is where 2.0 really improves life. Content can be passed through Apache modules that act as filters. It's similar to piping at a Unix/Linux command prompt. You can pipe a program's output to a string of filters, where each filter processes the content in a certain way.

"Multilanguage Error Responses -- Previous versions of Apache allowed content negotiation so a Web browser could request and receive content in a particular language. This has now been extended to Apache-generated error messages -- a great addition.

"I've converted one of my Web servers to 2.0, and I'll convert the others in time. For now, there's no hurry. Previous versions of Apache are stable."

Bottom line: for serving up plain-ole static pages, Apache 2.0 is fine 'n dandy, and should not present any difficulties. For users needing various modules, especially third-party modules, it depends on having the resources to deal with a platform still in flux. It may be worth it to get the increased performance benefits.

Finally, An Excellent Windows Apache
This is the first release of Apache for Windows that really struts its stuff. Previous versions were somewhat slower than their *nix cousins. Always solid, but rather plodding. Version 2.0, on the other hand, is ready for prime time. One of the biggest improvements is Unicode support for NT/2000/XP. URL and filename requests encoded in utf-8 means that Apache can access filenames in any language or characters.

It still looks like the same old Apache we know and love -- no fancy GUI, proper forward-slashes instead of backward-slashes, configuration via plain text files. It has some useful quick-click shortcuts: stop, start, edit httpd.conf, and test. And a service monitor that sits in the system tray. OK, that's not so much in the way of useful frills, but it's more than before. Editing a text configuration file is not as scary as it may seem for those unused to them. httpd.conf contains much useful information, and once you get the hang of it, it's fast, and easy to backup. A slick trick that can't be done with a GUI is to make multiple versions of httpd.conf, for easily testing different setups. Regardless of the interface, the user still needs to know network configuration, file locations, and so forth; there's still no substitute for knowledge.

Serving up static pages is dead easy. The learning curve gets steeper as you get into Apache's advanced functions, even to the point of writing your own custom modules. The sky's the limit, and Apache will do pretty much whatever you want it to.

Nicest of all is Apache's first-rate security. Anyone who has suffered through IIS security nightmares will surely appreciate the peace of mind that comes with Apache. Complacency is not yet a realistic option, however. One must keep up with patches and announcements. But Apache's reputation as a solid, secure platform is well-deserved.

The Platform of the Future
Apache has laid a foundation for future technologies, such as multiprotocol support, IPv6, and secure multiuser administration. This is one forward-looking reliable workhorse.

Apache Software Foundation

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved