Tune the on demand router (ODR)

ODRs are intelligent routers for SIP and HTTP traffic, acting as intermediaries for application servers and webs ervers. There are many factors that affect ODR performance; in order to get the optimal performance from the ODRs, it is sometimes necessary to tune them.

• Tune Java virtual machines. For more information, read about tuning the IBM virtual machine for Java.

• Remove all tracing information except for *=info, because this type of tracing impacts ODR performance. To change the tracing information, perform the following steps:

  1. Select Servers > Server types > On demand routers > on_demand_router > Troubleshooting > Logging and tracing > Diagnostic trace service > Change log detail levels.

  2. Ensure that only *=info is specified.

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

• Binary Trace Facility (BTF) has minimal impact on performance and can be left enabled

The default settings of the ODR work for most people, most of the time. For the installation, it may be necessary to carry out some or all of the following steps to obtain maximum performance. The steps are prioritized in order of importance.

1. Check the JVM settings. For more information about the JVM settings, read about modifying the JVM heap size for the on demand router.

2. 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, we can turn NIO to yield an increase in performance using the -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.DevPollSelectorProvider selector provider and disabling the extra poll before a read: -XX:-ExtraPollBeforeRead.

3. Tune the connection keep alive settings. For more information, read about tuning ODR persistent connections.

4. Tune the ODR maximum connections per server. For more information, read about tuning ODR maximum connections.

5. 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 additional overhead on the ODR may create a bottleneck at the ODR.

6. Disable access logging if not needed. If we 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.

7. Use the same thread group for both inbound and outbound work, which will avoid moving requests across threads and eliminates 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 we 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:

   1. Select Servers > Server types > On demand routers > on_demand_router > Thread pools > default_thread_pool > Custom properties > New.

   2. Specify combineSelectors for the name.

   3. Specify 1 for the value.

   4. Click OK.

   5. Click Save.

Subtopics

• (dist)(zos) Modify the JVM heap size for the on demand router
  The JVM heap size setting is the single most critical factor for efficient on demand router (ODR) performance. We might need to modify the JVM heap size setting based on the environment configuration.

• (dist)(zos) Tune ODR persistent connections
  Tune the persistent connection settings for ODR performance to minimize the time you spend setting up new connections and taking down older connections during a barrage of requests. Primarily, this tuning is relevant to the connections between the ODR and the application servers.

• (dist)(zos) Tune ODR maximum connections
  Increasing ODR maximum connections per server allows for more connections to be created and pooled, and enables keeping connections for a significant amount of time.

Related tasks

Tune ODR maximum connections

Create ODRs

Tune ODR persistent connections

Modify the JVM heap size for the on demand router

Related information:

Tune the IBM virtual machine for Java