# Introduction to WebLogic Real Time

# Tuning WebLogic Real Time

This section contains information on the following subjects:

- Basic Tuning Guidelines
- JVM Tuning for Real-Time Applications
- More Tuning Information

## Basic Tuning Guidelines

This section provides some basic tuning guidelines for configuring WebLogic Server, J2EE, and JMS applications for response-time sensitive applications.

### Basic Environment and Application Tuning

- Ensure that CPUs are not maxed out on servers or clients.
- Highly active Java clients may require running "deterministic" garbage collection as well.
- There may be a "warm-up" period of one-to-three minutes before response times achieve desired levels.
- For server-side EJBs, MDBs, and servlets ensure that there are enough concurrent instances configured to respond immediately to client requests (if all instances are active, this is a sign that client requests are queuing up behind each-other on the server).

### JMS Application Tuning

Use these guidelines when using WebLogic JMS applications with WebLogic Real Time.

- Consider using asynchronous consumers rather than synchronous consumers.

For more information on JMS consumers, see " Best Practices for Application Design" in Programming WebLogic JMS.

- Tune all JMS connection factory Messages Maximum settings to 1. This can potentially provide better latency at the expense of possibly lowering throughput. Similarly, configure your MDBs to refer to a custom connection factory with the following settings:

- Messages Maximum = `1`
- XA Connection Factory Enabled = `enabled`
- Client Acknowledge Policy = `ACKNOWLEDGE_PREVIOUS`

For more information on configuring JMS connection factories, see " Configure connection factories" in the Administration Console Online Help.

- For consumers of non-persistent messages from queues, consider using the WebLogic JMS WLSession NO_ACKNOWLEDGE extension.
- Ensure that your Spring JMS Templates leverage resource reference pooling (otherwise, they negatively impact response times as they implicitly create and close JMS connections, sessions, and producers once per message).

Note: | Resource reference pooling is not suitable if the target destination changes with each call, in which case change application code to use regular JMS and cache the JMS connections, sessions, producers, and consumers.

## JVM Tuning for Real-Time Applications

These tuning suggestions can further improve performance and decrease pause times when using the deterministic garbage collector.

- Setting the minimum heap size (`-Xms`) smaller or the maximum heap size (`-Xmx`) larger affects how often garbage collection will occur and determines the approximate amount of live data an application can have. See " -X Command-line Options" in the BEA JRockit Reference Manual.
- Increasing the page size (`-XXlargePages`) can increase performance and lower pause times by limiting cache misses in the translation look-aside buffer (TLB). See " -XX Command-line Options" in the BEA JRockit Reference Manual.
- Try to limit the amount of reference objects that are used, such as `Weak-`, `Phantom-`, and finalizers. These references require special handling, and if they occur in large numbers then pause times can become longer than 30ms.
- Running on slower hardware, with a different heap size and/or with more live data may break the deterministic behavior. In these cases, you might need to increase the pause time target by using the `-XpauseTarget` option. See " -X Command-line Options" in the BEA JRockit Reference Manual.
- Try adjusting the garbage collection trigger (`-XXgctrigger`) to limit the amount of heap space used. This way, you can force the garbage collection to trigger more frequent garbage collections without modifying your applications. The garbage collection trigger is somewhat deterministic, since garbage collection starts each time the trigger limit is hit. See " Adjust the Garbage Collection Trigger" in the BEA JRockit Configuration and Tuning Guide.

Note: | If the trigger value is set to low, the heap might get full before the garbage collection is finished, causing even longer pauses for threads since they have to wait for the garbage collection to complete before getting new memory. Typically, memory is always available since a portion of the heap is free and any pauses are just the small pauses when the garbage collection stops the Java application.

## More Tuning Information

This section contains pointers to additional performance and tuning information.

### JRockit JVM

- BEA JRockit Garbage Collection Models contains information on all of the JRockit garbage collection options.
- Tuning the JRockit JVM provides information on tuning the JRockit JVM.

### WebLogic Server

- WebLogic Server Performance and Tuning contains information on monitoring and improving the performance of WebLogic Server applications.
- Best Practices for Application Design in Programming WebLogic JMS provides design options for WebLogic Server JMS, application behaviors to consider during the design process, and recommended design patterns.