ODRs are servers that act as an intermediary for HTTP requests
that are serviced by application servers or Web servers. There are
many factors that affect ODR performance. If you discover that your
ODRs are not operating in the most optimal manner, then you might
want to tune your ODRs.
Before you begin
Before modifying the JVM heap size, read:
- Tuning Java virtual machines
- Remove all tracing information except for *=info, because additional
tracing strings impact ODR performance when tuning. To change the
tracing information, perform the following steps:
- Select Servers > On Demand Routers ><on
demand router> > Troubleshooting > Logging and
Tracing > Diagnostic Trace Service > Change Log Detail levels.
- Ensure that only *=info is specified.
- The on demand router (ODR) should never be constrained by either
CPU or memory usage. Therefore, when you install the ODR in an environment
with server virtualization, configure the virtual machine or LPAR
in which the ODR runs in dedicated processor mode, or configure it
in a mode that guarantees the ODR receives a sufficient amount of
CPU resources and dedicated memory when the ODR runs.
About this task
Use the topics in this section to troubleshoot your ODRs
when they are not operating in a typical fashion, or you are experiencing
unusual problems. For example, the following list contains tuning
suggestions for improving ODR performance in order of importance for
troubleshooting.
Procedure
- Check the JVM settings. See Modifying the JVM heap size for the on demand router (ODR).
HP and Sun provide additional tuning parameters
to optimize garbage collection. For generational garbage collection
JVMs such as Sun and HP, or IBM's J9 JVM when using gencon garbage
collection, set the permanent memory region to approximately 100MB
to encompass the base 90MB foot print that exists in the ODR. Further,
a SurvivorRation of 16 further optimizes processing in the young generation. On HP JVM, you can turn NIO to yield an increase in performance
by using the -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.DevPollSelectorProvider selector
provider and disabling the extra poll before a read: -XX:-ExtraPollBeforeRead.
- Tune the connection keep alive settings. See Tuning ODR persistent connections.
- Increase the ODR maximum connections per server. See Tuning ODR maximum connections
- Disable ODR caching when not in use. When the
ODR caching is enabled, the ODR must go through the process of determining
whether a request should be cached, then examine the cache repository
to check whether the request was previously cached. This causes additional
overhead.
- Disable access logging if not needed. If you
do need access logging, then the proxy logging is preferred over the
HTTP Channel/NCSA logging as the proxy access logging happens outside
of the request/reply path. Thus, it does not affect the response time
of the request. Access logging on a fairly fast disk is typically
5% overhead, but the percentage is highly dependant on disk performance.
- Use the same thread group for both inbound and outbound
work, which will avoid moving requests across threads and eliminate
the resulting overhead. The ODR has a set of threads that
tune itself under most circumstances. Queuing and throttling requests
are dispatched to the default thread pool, which you can tune so that
it will only handle the overflow requests. The primary thread group
will continue to handle most requests. All requests on the thread
pool are asynchronous with no blocking calls, so the number should
not be more than one or two threads per CPU. Complete the following
steps to use the same thread group for both inbound and outbound work:
- Select Servers > On Demand Routers > on
demand router > Thread Pools default thread pool >
Custom Properties > New
- Specify combineSelectors for the name.
- Specify 1 for the value.
- Click OK.
- Click Save.