Before you start to optimize your code and server configuration, you
need to consider the demands that will be placed on the hardware and
the operating system. There is no point in investing a lot of time
and money in configuration tuning and code optimizing only to find
that your server's performance is poor because you
did not choose a suitable platform in the first place.
Because hardware platforms and operating systems are developing
rapidly, the following advisory discussion must be in general terms,
without mentioning specific vendors' names.
8.1. Choosing the Right Operating System
This section discusses the characteristics
and features you should be looking for to support a mod_perl-enabled
Apache server. When you know what you want from your OS, you can go
out and find it. Visit the web sites of the operating systems that
interest you. You can gauge users' opinions by
searching the relevant discussions in newsgroup and mailing-list
archives. Deja (http://deja.com/)
and eGroups (http://egroups.com/)
are good examples. However, your best shot is probably to ask other
mod_perl users.
8.1.1. mod_perl Support for the Operating System
Clearly, before choosing an OS, you will
want to make sure that mod_perl even
runs on it! As you will have noticed throughout
this book, mod_perl 1.x is traditionally a Unix-centric solution.
Although it also runs on Windows, there are several limitations
related to its implementation.
The problem is that Apache on Windows uses a multithreaded
implementation, due to the fact that Windows can't
use the multi-process scheme deployed on Unix platforms. However,
when mod_perl (and thereby the Perl runtime) is built into the Apache
process, it cannot run multithreaded, because
before Version 5.8.0 the Perl runtime wasn't
thread-safe.
What does this mean for you? Well, essentially it means that your
Apache process will be able to serve only one request at a
time, just like when using httpd -X.
Of course, this becomes a severe performance hit, making you unable
to have more than one user receiving a page at a time. The situation
is resolved in mod_perl 2.0, however, thanks to advances in both
Apache and Perl, as described in Chapter 24.
Furthermore, you can still use mod_perl on Windows for development,
although you should follow the considerations below when choosing the
production OS.
8.1.2. Stability and Robustness
Probably the most important features in an OS are
stability and robustness. You are in an Internet business. You do not
keep normal 9 A.M. to 5 P.M. working hours like many conventional
businesses you know. You are open 24 hours a day. You cannot afford
to be offline, because your customers will go shop at another service
like yours (unless you have a monopoly). If the OS of your choice
crashes every day, first do a little investigation. There might be a
simple reason that you can find and fix. However, there are OSes that
won't work unless you reboot them twice a day. You
don't want to use an OS of this kind, no matter how
good the OS's vendor sales department is. Do not
follow flush advertisements—follow developers'
advice instead.
Generally, people who have used an OS for some time can tell you a
lot about its stability. Ask them. Try to find people who are doing
similar things to what you are planning to do; they may even be using
the same software. There are often compatibility issues to resolve,
and you may need to become familiar with patching and compiling your
OS.
8.1.3. Good Memory Management
You want an OS with a good memory-management
implementation. Some OSes are well known as memory hogs. The same
code can use twice as much memory on one OS compared to another. If
the size of the mod_perl process is 10 MB and you have tens of these
processes running, it definitely adds up!
8.1.4. Avoiding Memory Leaks
Some OSes and/or their libraries (e.g., C runtime libraries)
suffer from memory leaks. A leak is when some
process requests a chunk of memory for temporary storage but then
does not subsequently release it. The chunk of memory then
won't be available for any purpose until the process
that requested it dies. You cannot afford such leaks. A single
mod_perl process sometimes serves thousands of requests before it
terminates; if a leak occurs on every request, the memory demands
could become huge. Of course, your code can be the cause of the
memory leaks as well, but that's easy to detect and
solve. Certainly, you can reduce the number of requests to be served
over the process's life, but that can degrade
performance. When you have so many performance concerns to think
about, do you really want to be using faulty
code that's not under your control?
8.1.5. Memory-Sharing Capabilities
You want an OS with good memory-sharing
capabilities. If you preload the Perl modules and scripts at server
startup, they are shared between the spawned children (at least for
part of a process's life—memory pages can
become "dirty" and cease to be
shared). This feature can vastly reduce memory consumption.
Therefore, you don't want an OS that
doesn't have memory-sharing capabilities.
8.1.6. The Real Cost of Support
If you are in a big business, you probably do not mind
paying another $1,000 for some fancy OS with bundled support. But if
your resources are low, you will look for cheaper or free OSes. Free
does not mean bad. In fact, it can be quite the opposite—some
of the free OSes have the best support available.
This is easy to understand—most people are not rich and will
try to use a cheaper or free OS first if it does the work for them.
If it fits their needs, they will keep using it and eventually come
to know it well enough to be able to provide support for others in
trouble. Why would they do this for free? One reason is the spirit of
the first days of the Internet, when there was no commercial Internet
and people helped each other because someone else had helped them
first. We were there, we were touched by that spirit, and we are keen
to keep that spirit alive.
Nevertheless, we are living in a material world, and our bosses pay
us to keep the systems running. So if you feel that you cannot
provide the support yourself and you do not trust the available free
resources, you must pay for an OS backed by a company to which you
can turn in case of problems. Insufficient support has often been
characterized as an important drawback of open source products, and
in the past it may have been the main reason for many companies to
choose a commercial product.
Luckily, in recent years many companies have realized how good the
open source products are and started to provide official support for
these products. So your suggestion of using an open source operating
system cannot be dismissed solely on the basis of lacking vendor
support; most likely you will be able to find commercial support just
like with any other commercial OS vendor!
Also remember that the less money you spend on an OS and software,
the more you will be able to spend on faster and stronger hardware.
Of course, for some companies money is a non-issue, but there are
many companies for which it is a major concern.
8.1.7. Discontinued Products
You might find yourself in a position
where you have invested a lot of time and money into developing some
proprietary software that is bundled with the OS you chose (say,
writing a mod_perl handler that takes advantage of some proprietary
features of the OS and that will not run on any other OS). Things are
under control, the performance is great, and you sing with happiness
on your way to work. Then, one day, the company that supplies your
beloved OS goes bankrupt (not unlikely nowadays), or they produce a
newer, incompatible version and decide not to support the old one (it
happens all the time). You are stuck with their early masterpiece, no
support, and no source code! What are you going to do? Invest more
money into porting the software to another OS?
The OSes in this hazard group tend to be developed by a single
company or organization, so free and open source OSes are probably
less susceptible to this kind of problem. Their development is
usually distributed between many companies and developers, so if a
person who developed a really important part of the kernel loses
interest in continuing, someone else usually will pick up the work
and carry on. Of course, if some better project shows up tomorrow,
developers might migrate there and finally drop the development, but
in practice people are often given support on older versions and
helped to migrate to current versions. Development tends to be more
incremental than revolutionary, so upgrades are less traumatic, and
there is usually plenty of notice of the forthcoming changes so that
you have time to plan for them.
Of course, with the open source OSes you have the source code, too.
You can always have a go at maintaining it yourself, but do not
underestimate the amount of work involved.
8.1.8. Keeping Up with OS Releases
Actively developed OSes generally
try to keep pace with the latest technology developments and
continually optimize the kernel and other parts of the OS to become
better and faster. Nowadays, the Internet and networking in general
are the hottest topics for system developers. Sometimes a simple OS
upgrade to the latest stable version can save you an expensive
hardware upgrade. Also, remember that when you buy new hardware,
chances are that the latest software will make the most of it.
If a new product supports an old one by virtue of backward
compatibility with previous products of the same family, you might
not reap all the benefits of the new product's
features. You might get almost the same functionality for much less
money if you were to buy an older model of the same product.
