HTTP server performance tuning

You can tune the IBM® HTTP Server to improve Maximo® Asset Management response times. You can customize your parameter settings to improve performance.

You can use the IBM HTTP Server parameter settings to optimize tuning. These settings are used for tuning performance in a test environment, and so your environment might require different settings. You can use these settings as a guideline or as a starting point, and then monitor and tune the settings to your environment.

The versions of IBM HTTP Server and of WebSphere® Application Server must be the same.

The following parameter settings were optimized and tested for the Microsoft Windows environment. Although these same settings were also tested and optimized in an AIX® environment, they are not optimized for UNIX or Linux.

IBM HTTP Server working on a Windows environment has a parent process and a single, multithreaded child process which creates simultaneous connections. Set the following parameters so that your environment can handle the simultaneous connections more efficiently:

TimeOut
The amount of time that the server waits for certain events before a request is rejected.
  • Value: 900
KeepAliveTimeOut
The amount of time that the server waits for subsequent requests on a persistent connection. Set this value to 60 for those environments that have high network latency. For example, network latency can be an issue when users are in areas that are geographically different from the location of the servers. That means the further the users are located from the servers, the higher the network latency is.
  • High network bandwidth: 10
  • Low network bandwidth: 60
MaxKeepAliveRequests
The number of requests allowed on a persistent connection. If you limit the number of requests, the server must finish the connection and create another connection when the limit is reached. The need to finish and create connections continuously can affect server performance. Set this value to zero to allow unlimited requests on a persistent connection.
  • Value: 0
MaxRequestsPerChild
The limit on the number of requests that an individual child process handles during its lifecycle. After this limit is reached, the child process ends. When you set this value to 0, the child process never ends and can handle unlimited requests. If you set this value to a number greater than 0, extra processing is required to terminate and create child processes. On Linux and UNIX systems, a value other than 0 can create a high number of child processes, which can result in excessive swap space usage. To minimize potential issues, set this value to 0.
  • Value: 0
ThreadLimit
The upper limit on the configurable number of threads per child process.
  • Value for Windows environments: 2400
ThreadsPerChild
The number of threads that each child process can create. In a Windows environment runing on 64 bits, each instance is limited to 2500 threads per child approximately. For the 32-bit environments, the total number of threads per child is closer to 5000. These numbers are not exact limits because the actual limits are the sum of the startup memory that is used by each thread plus the maximum runtime memory usage per thread. That sum varies based on configuration and workload. If you raise the number of the ThreadsPerChild parameter, you risk having child processes that do not work when the runtime memory raises the address space over 2 or 3 GB.
  • Value for Windows environments: 2400
You can set the ThreadsPerChild and ThreadLimit parameters to the same value.


Feedback