In my last article, we discussed how to configure and install Apache 2.0. That's a good start, but it doesn't go far enough for anybody who is currently running a server on Apache 1.3. Not only do you want to configure and install Apache 2.0, but you also need to ensure that when migrating, you upset your service for as little time as possible.
All of the lessons learned in this article come from porting the apache.org web server to Apache 2.0. This was done last December, long before the first beta was released, so while some of the details will not apply anymore, the lessons learned are all still valid. I also need to give credit where it is due: I never did get apache.org running Apache 2.0. I started it and then, for personal reasons, I left the job for Greg Ames to finish. I watched what he did, and helped with some of the problems that were encountered, but Greg is the person who succeeded in getting apache.org onto a 2.0 server.
When planning for making the change over, our first priority was to not interrupt service on apache.org at all. Apache.org is not the busiest site on the Web, but in the middle of the day we can get hit pretty hard, and when our site goes down people take notice. With that in mind, we planned to put an installation of Apache 2.0 on port 8091 and announce that server so that we could watch how well it handled. After a week of allowing people to stress test the server, we would turn it on live on port 80.
Even before trying to setup our server, we had to make some decisions. Apache 2.0 is much more flexible than Apache 1.3 when it comes to configuring the server. The first decision to make is which Multiprocessing Module (MPM) to use. (For a full description of MPMs, see my first article in this series.)
I suggest starting with the prefork MPM. Enough has changed with Apache 2.0 that it will help to start with a model that is well understood and is known to work. Once your new Apache 2.0 server is up and serving pages, you can start to experiment with new MPMs to determine which will work best for your site.
Interested in asking Ryan a few more questions? Post them here, and we'll try to find the answers to help your migration.
MPMs can affect your server beyond just how processes and threads are created. The best example of this is
mod_cgid. Most versions of Unix do not fork threaded processes well; instead of creating a new single-threaded process, they tend to copy the entire process, including all of the threads, and then kill off all but one thread. Obviously, this is not a very efficient way to create processes.
The solution that the Apache developers have created is to have a CGI daemon that Apache uses to create new CGI processes. This daemon process is created before any child processes are created, and it is a single-threaded process. When a CGI request is received, it is sent to the CGI daemon, and that daemon process forks to create the CGI process. The CGI process then sends the resulting data back to the child process to be sent to the client. This module is not as advanced as the standard
mod_cgi, so if you are setting up your server with a threaded MPM, and you find CGI requests are causing trouble, you may want to downgrade to
mod_cgi to determine if the problem still exists.
mod_cgi will still work with threaded MPMs, but its performance will not be optimal.
The final major difference between Apache 1.3 and 2.0 is the addition of filters. For programmers, filters are a powerful way to modify data that another module creates. For administrators, filters require that some topics be completely rethought. The only standard module that implements a filter is
mod_include, so we will focus on that module. In Apache 1.3, if you wanted all
.shtml files to be parsed for server-side includes, you would use a line like
AddHandler server-parsed .shtml
In Apache 2.0, there is no server-parsed handler, so this does not work. Instead, you need to add the INCLUDES filter with a line like
This directive can be specified in Files, Directory, or Location containers to make sure that any data being sent to the client can be parsed for server-side includes. This does mean that your config file may get larger and harder to read. It also means that mime-types aren't as important as they once were in Apache, and Handlers are no longer very important, either. Most modules that generate data will just use the default-handler to read a file from the disk, and use a filter to modify that data.
Unfortunately, setting up our server proved much harder than we originally expected. The first problem we hit was specifying virtual hosts; one machine hosts all of the Apache.org sites, so obviously we consider this an important ability for the server. The problem we had was that apache.org runs on a platform that understands both IPv4 and IPv6. Apache 2.0 supports IPv6 automatically, but the problem is that on platforms that support IPv6, it is supported too well.
If your platform supports IPv6, it is very difficult to make Apache 2.0 use IPv4. The Apache developers have discussed using a configuration flag to determine which type of address to use; however, this directive has not been implemented yet. For now, if you find that you have problems accessing your server, the problem is likely to be the IPv6 support. To solve this problem, you can use the
* specifier throughout your config file to specify IP addresses. This will cause your server to bind to the same port on all addresses.
Once we did get the server running on port 8091, we let it run for a week before turning it on live. When we did, we found that the server was not really stable enough to go live, and the machine stopped responding after a few hours.
Why did that happen? Just because a server is tested, that doesn't mean it will work as a live server. There are many subtle differences between browsers that can cause small bugs that are difficult to find.
The above issues are the ones that caused us the most trouble as we migrated the apache.org site from 1.3 to 2.0. While this article does not cover every problem you will have while moving to Apache 2.0, I hope that I have provided an answer to the most common issues, and given you a starting point for your own migration.
I would remind you that Apache only gets better when users provide feedback to the developers, so if you find a problem that you can not solve, please post bugs to the bug database at http://bugs.apache.org and use the newsgroups mentioned there for more help. Many of the Apache developers spend time on the newsgroups, and are happy to help in any way we can.
In my next column, I'll explain how to write filters, a new mechanism for enabling one module to modify another.
Ryan Bloom is a member of the Apache Software Foundation, and the Vice President of the Apache Portable Run-time project.
Read more Apache 2.0 Basics columns.
Return to the Apache DevCenter.
Copyright © 2009 O'Reilly Media, Inc.