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.
- 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.
- 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.
- 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.