Web servers have become one of the fundamental building blocks of the business world's IT infrastructure. The two big names in today's Web server market are Microsoft IIS, which has long dominated the Windows Server market, and the Apache HTTP Server, which has been the favorite for other OS implementations, most notably UNIX.
In recent years, IIS has come under fire for various reasons, especially for security concerns. But what other viable Web server options have Windows shops had? Apache, which the Apache Group manages, is a powerful, sophisticated, and mature Web server that many regard as a crowning achievement of the open-source community. And many companies that use Apache in their products—for example, IBM, which uses Apache in its WebSphere product—actively contribute to and support Apache, so the Web server continues to grow and adapt to the fast-changing business environment. However, the product's use on Windows platforms has been limited—until now.
With the release of Apache 2.0, this popular, highly reliable and scalable Web server has increased its portability and performance on the Windows platform and improved extensibility across all platforms. The new version's improvements mean that you can use Apache's power to your advantage, even if your organization runs Windows 2000 or Windows NT.
Improved Portability and Performance
The Apache Group's original goals were security and stability. In Apache 1.3, the development team created a secure, reliable, and highly available server that could scale under heavy loads. That version has long been the Web server of choice on just about every non-Windows platform (e.g., Linux, OS/2, Sun Microsystems' Solaris) and even runs on Win2K, NT, and Windows 98. However, Apache 1.3's high level of scalability doesn't extend to the product's Windows port, so Apache hasn't been a true competitor of IIS in organizations that run Windows. The Apache Group decided a new design was necessary to deal with key concerns across all platforms, most notably code complexity (which would have made Apache increasingly more difficult to improve and fix over time) and performance.
The Apache Group's efforts to support more platforms originally came in the form of conditional compilation, which means that only certain code is compiled into a program, depending on whether a stated condition (e.g., the OS in use is Solaris) is true. As the number of supported platforms expanded and variations among supported platforms increased, the Apache code base rapidly grew extremely complex and the use of conditional compilation quickly became a hindrance to development. Performance was another factor that the Apache Group needed to deal with. Apache relied on some basic assumptions about how to treat CPUs, I/O, memory, and processes. This reliance wasn't a problem on most UNIX systems because Apache was developed on and primarily for that platform. However, the architectural model around which Apache was built didn't work well on non-UNIX OSs and even on some types of UNIX, so these assumptions led to scalability problems on those platforms.
The Apache Group decided to deal with both concerns in one fell swoop, building Apache 2.0 on an abstract layer and tuning that layer's implementation to the underlying platform. As a result, Apache 2.0 provides major improvements in both portability and performance.
One of the abstractions now built into Apache 2.0 is the Apache Portable Runtime (APR). As Figure 1, page 118, shows, the APR serves as an interface between the OS and the Apache HTTP Server and handles system services such as I/O, shared memory, and child-process management. The APR, however, doesn't affect the model that Apache uses when handling concurrent client connections, which was Apache's primary performance problem on Windows. Earlier Apache versions assume that the underlying OS can efficiently create child processes. But some OSs, such as Windows and IBM AIX, better support multithreading, so using child processes to handle client-network connections isn't an optimal solution on those platforms. Instead, Apache needed to use a thread to handle each connection. (Multithreading isn't as resilient to errors as using multiple processes. An errant thread can cause problems for other threads, whereas in a multiple-process design, each process is essentially independent. However, Windows servers use the multithreading model, so a certain—albeit minimal—trade-off of reliability for the sake of performance was necessary.)
The Apache Group's solution—Multi-Processing Modules (MPMs)—are both theoretically simple and elegant in implementation. MPMs create an abstraction between Apache and the method used to handle concurrent client connections. The idea is that the Apache Group—or a developer who wants to support a new platform—builds an MPM specific to a given architecture or feature specification (e.g., using child processes, multithreading, or the combination that best fits a particular user's needs). During the configuration process, the Apache user chooses the MPM that best suits the user's environment, although by default the configuration file that comes with each port of Apache uses the MPM specific to that platform. Apache then relies on the MPM to handle the low-level details of handling concurrent client connections. For Windows systems, Apache uses the winnt MPM. As Figure 2 shows, this MPM works by having the Apache server create a child process, which then creates and controls the necessary threads to service each client connection. (A parent process is necessary in this case to create a new process if the client process dies.)
Increased Extensibility
Apache 1.3 was already extensible because of the server's reliance on modules, a type of Apache add-on component. A module is simply software that uses the open Apache Module API. Despite the power of the existing Module API, the Apache Group developed a new and improved API for module writers and a new framework from which that API operates. Although this change means that modules written for earlier Apache versions don't work with Apache 2.0, the change increases Apache modules' abilities in several fundamental ways, such as providing a powerful new filtering capability. During configuration, you can use this filtering capability to layer modules and create complex systems. Even better, filtering can simplify the way that modules interact with Apache. For example, under earlier Apache versions, the only way to add Secure Sockets Layer (SSL) support was to modify Apache itself. Under Apache 2.0, however, SSL is simply an add-on module. Table 1 lists several Apache 2.0 modules and their purposes. (To view a list of Apache modules available with the Apache installation, examine the LoadModule directives in httpd.conf and the associated module binaries in \program files\apache group\apache2\modules. To view a more comprehensive list, visit the Apache Web site at http://httpd.apache.org/docs-2.0/mod.)
Prev. page
[1]
2
3
next page 
