IBM HTTP Server 2.0

Although IHS 1.3.28 is installed as the default Web server if you select a full installation of WAS V5.1, IBM introduced plug-in support for IHS 2.0 in Application Server V5.0. If you want to use the IHS 2.0 Web server, you first have to download and install IHS 2.0 from 

http://www.ibm.com/software/webservers/httpservers/

For details on installing and upgrading from IHS V1.3.x to V2.0.x, refer to the following InfoCenter article: navigate to Installation -> Getting Started -> Preparing to install and configure a Web server. There, select the topic Installing IBM HTTP Server powered by Apache 2.0. The easiest and recommended way is to install IHS 2.0 before installing WAS. Then select the plug-in for version 2.0 to have the installer configure IHS 2.0 to work with WAS V5.1.

First we give you a short introduction into IBM HTTP Server 2.0, for example on the new features. For IHS 2.0 tuning information go to Tuning IHS 2.0.

 

New Features

There are various changes in IHS 2.0, and this section describes specific issues to consider to help you determine whether to migrate your system from IHS 1.3 to 2.0. Following are a few important new features of IHS 2.0. For a complete feature list, visit the Apache 2.0 Web site at

http://httpd.apache.org/docs-2.0/new_features_2_0.html

  1. IHS 2.0 is a thread-based Web server

    Although IHS 1.3 is thread-based on the Windows platform, it is a process-based Web server on all Unix and Linux platforms. That means, it implements the multi-process, single-thread process model: for each incoming request, a new child process is created or requested from a pool to handle it.

    However, IHS 2.0 is now a fully thread-based Web server on all platforms. This gives you the following advantages:

    1. Each request does not requires its own HTTPD process anymore, and less memory is needed.

    2. Overall performance improves because in most cases new HTTPD processes do not need to be created.

    3. The plug-in load-balancing and failover algorithms work more efficiently in a single-process, multi threaded HTTP server. If one plug-in thread marks an appserver unavailable, all other connection threads of the plug-in will share that knowledge, and will not try to connect to this particular application server again before the RetryInterval has elapsed. See 5.7, Web server plug-in behavior and failover for information on the RetryInterval parameter and plug-in load balancing and failover issues.

    Note On the Unix platform, IHS 2.0 also allows you to configure more than one process to be started.

  2. The mod_deflate module

    This module allows supporting browsers to request that content be compressed before delivery. It provides the Deflate output filter that lets output from the server be compressed before it is sent to the client over the network. Some of the most important benefits of using the mod_deflate module are:

    • Saves network bandwidth during data transmission
    • Shortens data transmission time
    • Generally improves overall performance

    Detailed information about configuring and using mod_deflate can be found at

    http://httpd.apache.org/docs-2.0/mod/mod_deflate.html

  3. Request and response filtering

    Apache (and IHS) modules may now be written as filters which act on the stream of content as it is delivered to or from the server.

  4. No GUI-based administration tool

    IHS 2.0 does not contain a GUI-based administration tool anymore. Changes have to be performed manually on the httpd.conf file using an editor. If browser based administration is imperative for you, not upgrade to IHS 2.0.

 

Configuration migration

Be sure to review your IHS 1.3.x httpd.conf configuration file to see what modules are loaded and which directives are set, because of the following reasons:

  1. Many IHS 1.3 directives remain unchanged in IHS 2.0. Notable exceptions relate primarily to new IHS 2.0 functions, such as filtering and Unix thread support.

  2. IHS 2.0 contains some new directives.

  3. In IHS 2.0, some 1.3 directives have been deprecated.

Do not overwrite the new IHS 2.0 httpd.conf with your IHS 1.3.x one because this will not work.

After installing WAS V5.1, verify that all needed WebSphere plug-in directives were added to the IHS 2.0 configuration file.

The following examples show the WebSphere plug-in directives that must be added to httpd.conf for IHS 2.0 running on Unix (see Example 19-9; on the Windows platform this is similar).

Example 19-9 Plug-in directives that must be added to httpd.conf for IHS 2.0 on Unix. 

Alias  /IBMWebAS/   <wasroot>/web/
Alias  /WSsamples   <wasroot>/WSsamples/
LoadModule  was_ap20_module   <wasroot>/bin/mod_was_ap20_http.so
WebSpherePluginConfig   <wasroot>/config/cells/plugin-cfg.xml

 

Single-processing versus multi-processing

Apache version 2 (and thus IHS 2) achieves efficient support of different operating systems by implementing a Multi-Processing Modules (MPM) architecture, allowing it, for example, to use native networking features instead of going through an emulation layer in version 1.3. For detailed information about MPM refer to the Apache HTTP Server documentation found at: 

http://httpd.apache.org/docs-2.0/mpm.html

MPMs are chosen at compile time and differ from operating system, which implies that the Windows version uses a different MPM module than the AIX or Linux version. The default MPM for Windows is mpm_winnt, whereas the default module for AIX is mpm_worker. For a complete list of available MPMs, refer to the Apache MPM documentation URL above. To identify which was MPM compiled into an Apache 2.0 or IHS 2.0 Web server, run the httpd -l command, which prints out the module names. Look for a module name worker, or a name starting with the mpm prefix (see Example 19-10).

Example 19-10 Listing of compiled in modules for IHS 2.0 on AIX 

root@app2:/usr/IBMIHS/bin $ ./httpd -l
Compiled in modules: core.c worker.c http_core.c mod_suexec.c mod_so.c

  1. mpm_winnt module

    This Multi-Processing Module is the default for the Windows operating systems. It uses a single control process which launches a single child process which in turn creates all the threads to handle requests.

  2. mpm_worker module

This Multi-Processing Module implements a hybrid multi-process multi-threaded server. This is the default module for AIX. By using threads to serve requests, it is able to serve a large number of requests with less system resources than a process-based server. Yet it retains much of the stability of a process-based server by keeping multiple processes available, each with many threads.

 

Tuning IHS 2.0

This section gives you configuration tips for the Unix and Windows platform that provide a good starting point for Web server tuning, and an explanation of the new configuration directives used. Keep in mind that every system and every site has different requirements, so make sure to adapt these settings to your needs! See Example 19-11 for a Unix sample configuration and Example 19-12 for a Windows sample configuration.

  1. ThreadsPerChild

    Each child process creates a fixed number of threads as specified in the ThreadsPerChild directive. The child creates these threads at startup and never creates more. If using an MPM like mpm_winnt, where there is only one child process, this number should be high enough to handle the entire load of the server. If using an MPM like worker, where there are multiple child processes, the total number of threads should be high enough to handle the common load on the server.

  2. ThreadLimit

    This directive sets the maximum configured value for ThreadsPerChild for the lifetime of the Apache process. ThreadsPerChild can be modified during a restart up to the value of this directive.

  3. MaxRequestsPerChild

    This directive controls after how many requests a child server process is recycled and a new one is launched.

  4. MaxClients

    This controls the maximum total number of threads that may be launched.

  5. StartServers

    The number of processes that will initially be launched is set by the StartServers directive.

  6. MinSpareThreads and MaxSpareThreads

    During operation, the total number of idle threads in all processes will be monitored, and kept within the boundaries specified by MinSpareThreads and MaxSpareThreads.

  7. ServerLimit

    The maximum number of processes that can be launched is set by the ServerLimit directive.

Example 19-11 A sample configuration for the Unix platform 

<IfModule worker.c>
ServerLimit 1
ThreadLimit 2048
StartServers 1
MaxClients 1024
MinSpareThreads 1
MaxSpareThreads 1024
ThreadsPerChild 1024
MaxRequestsPerChild 0
</IfModule>

Using a ThreadsPerChild value greater than 512 is not recommended on the Linux and Solaris platform. If 1024 threads are needed, the recommended solution is to increase the ServerLimit value to 2 to launch two server process with 512 threads each.

Example 19-12 A sample configuration for the Windows platform 

<IfModule mpm_winnt.c>
ThreadsPerChild 2048 MaxRequestsPerChild 0 </IfModule>

  Prev | Home | Next

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.

 

AIX is a trademark of the IBM Corporation in the United States, other countries, or both.