Apache can do a wide range of things, not all of which are needed on
every web site. Those that are needed are often not all needed all
the time. The more capability the executable,
httpd, has, the bigger it is. Even though
RAM is cheap, it isn’t so cheap that the size of the
executable has no effect. Apache handles user requests by starting up
a new version of itself for each one that comes in. All the versions
share the same static executable code, but each one has to have its
own dynamic RAM. In most cases this is not much, but in some — as
in mod_perl (see Chapter 17) — it can be huge.
The problem is handled by dividing Apache’s functionality into modules and allowing the webmaster to choose which modules to include into the executable. A sensible choice can markedly reduce the size of the program.
There are two ways of doing this. One is to choose which modules you want and then to compile them in permanently. The other is to load them when Apache is run, using the Dynamic Shared Object (DSO) mechanism — which is somewhat like Dynamic Link Libraries (DLL) under Windows. In the two previous editions of this book, we deprecated DSO because:
It was experimental and not very reliable.
The underlying mechanism varies strongly from Unix to Unix so it was, to begin with, not available on many platforms.
However, things have moved on, the list of supported platforms is much longer, and the bugs have been ironed out. When we went to press, the following operating systems were supported:
|
Linux |
SunOS |
UnixWare |
|
Darwin/Mac OS |
FreeBSD |
AIX |
|
OpenStep/Mach |
OpenBSD |
IRIX |
|
SCO |
DYNIX/ptx |
NetBSD |
|
HPUX |
ReliantUNIX |
BSDI |
|
Digital Unix |
DGUX |
Ultrix was entirely unsupported. If you use an
operating system that is not mentioned here, consult the notes in
INSTALL.
More reasons for using DSOs are:
Web sites are also getting more complicated so they often positively need DSOs.
Some distributions of Apache, like Red Hat’s, are supplied without any compiled-in modules at all.
Some useful packages, such as Tomcat (see Chapter 17), are only available as shared objects.
Having said all this, it is also true that using DSOs makes the novice webmaster’s life more complicated than it need be. You need to create the DSOs at compile time and invoke them at runtime. The list of them clogs up the Config file (which is tricky enough to get right even when it is small), offers plenty of opportunity for typing mistakes, and, if you are using Apache v1.3.X, must be in the correct order (under Apache v2.0 the DSO list can be in any order).
Our advice on DSOs is not to use them unless:
You have a precompiled version of Apache (e.g., from Red Hat) that only handles modules as DSOs.
You need to invoke the DSO mechanism to use a package such as Tomcat (see Chapter 17).
Your web site is so busy that executable size is really hurting performance. In practice, this is extremely unlikely, since the code is shared across all instances on every platform we know of.
If none of these apply, note that DSOs exist and leave them alone.