Tune Web servers

WebSphere Application Server provides plug-ins for several Web server brands and versions. Each Web server operating system combination has specific tuning parameters that affect the application performance.

Overview

Following is a list of tuning parameters specific to Web servers. The listed parameters may not apply to all of the supported Web servers. Check your Web server documentation before using any of these parameters.

Procedure

• Tune the IBM HTTP Server 2.0.47.1, Apache 2.0.48, IBM HTTP Server 6.0, and IBM HTTP Server 6.1. Monitoring the CPU utilization and checking the IBM HTTP Server error_log and http_plugin.log files can help you diagnose Web server performance problems.

  You can also configure the IBM HTTP Server to show a status page:

  • Edit the IBM HTTP Server httpd.conf file and remove the comment character (#) from the following lines in this file:

    #LoadModule status_module, modules/ApacheModuleStatus.dll, 
    #<Location/server-status>
    #SetHandler server-status
    #</Location>
     
    

  • Save the changes and restart the IBM HTTP Server.

  • In a Web browser, go to: http://yourhost/server-status. Alternatively, click Reload to update status.

  • (Optional) If the browser supports refresh, go to http://your_host/server-status?refresh=5 to refresh every five seconds.

  All of these Web servers allocate a thread to handle each client connection. Ensuring that enough threads are available for the maximum number of concurrent client connections helps prevent this tier from being a bottleneck. The settings for these Web servers can be tuned by making changes to the httpd.conf file on the Web server system.

  You can check the IBM HTTP Server error_log file to see if there are any warnings about having reached the maximum number of clients (MaxClients). There are several parameters, depending on the specific operating system platform, that determine the maximum number of clients the Web server supports. See http://httpd.apache.org/docs-2.0/mod/mpm_common.html#maxclients for a description of the MaxClients parameters.

• Support thousands of concurrent clients. It is not unusual for a single IBM HTTP Server system to support thousands of concurrent clients. If your requirements are to support more concurrent clients than the number of threads that are supported by the Web server operating system and hardware, consider using multiple Web servers.

• Respond to a Connection Refused error message. Some clients might receive a Connection Refused error message if there is a sudden increase in the number of clients. Increasing the ListenBacklog and StartServer parameters can reduce or eliminate this error.

  • The ListenBacklog parameter indicates to the operating system the maximum allowed number of pending connections. Although the IBM HTTP Server default is 511, the actual value can be much higher or lower depending on the corresponding operating system parameter. To handle large numbers of simultaneous connections, this parameter and the corresponding OS parameter might need to be set to the number (possibly thousands) of expected simultaneous connections. (See Tuning operating systems for additional information on how to tune your operating system.

  • The StartServers parameter indicates the number of IBM HTTP Server processes to initially start. Pre-starting these IBM HTTP Server threads/processes reduces the chance of a user having to wait for a new process to start. You should set this parameter to a value equal to the MinSpareServers parameter so that the minimum number of IBM HTTP Server processes needed for this client load is started immediately.

• Prevent the frequent creation and destruction of client threads/processes as the number of users change. You can use the MinSpareServers and MaxSpareServers to specify the minimum and maximum number of servers (client threads or processes) that can exist in an idle state. To prevent frequent creation and destruction of client threads/processes as the number of users change, set this range large enough to include the maximum number of simultaneous users.

• Change the setting on the Web server's Access logging parameter to reduce the load on the Web server. If you do not need to log every access to the Application Server, change the default value of the Web server's Access logging parameter. This change will reduce the load on the Web server.

• Modify the settings of the Load balancing option and Retry interval Web server plug-in properties to improve performance. You can improve the performance of IBM HTTP Server (with the WebSphere Web server plug-in) by modifying the following Web server plug-in configuration properties:

  • Load balancing option, which specifies the load balancing option that the plug-in uses in sending requests to the various application servers associated with that Web server.

    The goal of the default load balance option, Round Robin, is to provide an even distribution of work across cluster members. Round Robin works best with Web servers that have a single process sending requests to the Application Server. If the Web server is using multiple processes to send requests to the Application Server, the Random option can sometimes yield a more even distribution of work across the cluster.

  • Retry interval. which specifies the length of time to wait before trying to connect to a server that has been marked temporarily unavailable.

    The plug-in marks a server temporarily unavailable if the connection to the server fails. Although a default value is 60 seconds, you might have to lower this value in order to increase throughput under heavy load conditions. Lowering the RetryInterval might help when the IBM HTTP Server is configured to have fewer than 10 threads per process.

    How can lowering the RetryInterval affect throughput? If the plug-in attempts to connect to a particular application server while the application server threads are busy handling other connections, which happens under heavy load conditions, the connection might time out, causing the plug-in to mark the server temporarily unavailable. If the same plug-in process has other connections open to the same server and a response is received on one of these connections, the server is marked again. If there are only a few threads per IBM HTTP Server process, there might not be an established connection to this application server . When this situation occurs, the plug-in must wait for the entire retry interval.

    Note: Although lowering the RetryInterval can improve performance, if all the application servers are running, a low value can have an adverse affect when one of the application servers is down. In this case, each IBM HTTP Server process attempts to connect and fail more frequently, resulting in increased latency and decreased overall throughput.

  Making these changes can help the IBM HTTP Server to support more WebSphere Application Server users. To modify these properties, in the administrative console, click Servers > Web Servers > Web_server_name > Plug-in properties > Request routing . (See Web server plug-in tuning tips For more information on tuning the plug-in.)

What to do next

For more information about tuning heavily loaded Web servers, see Performance: Resources for learning

Related tasks