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.





8.1.7 Discontinued Products




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.

    Part I: mod_perl Administration
    Part II: mod_perl Performance
    Part VI: Appendixes