performancewiki.com - Top Tuning Recommendations for WebLogic Server

performance / tuning tips. to the point.

del.icio.us performancewiki.com Latest Items

Top Tuning Recommendations for WebLogic Server

Tune the Operating System
Optimize Your Database
Identify the Best JVM Settings
Monitor Disk and CPU Utilization

Tune the OS

UNIX Tuning Parameters

For better TCP (transmission control protocol) socket performance, set the tcp_time_wait_interval parameter. This parameter determines the time interval that a TCP socket is kept alive after issuing a close call. The default value of this parameter on Solaris is four minutes. When a large number of clients connect for a short amount of time, holding these socket resources can have a significant negative impact on performance. Setting this parameter to a value of 60000 (60 seconds) has shown a significant throughput enhancement when running benchmark JSP tests on Solaris. You might want to reduce this setting further if the server gets backed up with a queue of half-opened connections.

# ndd -set /dev/tcp tcp_time_wait_interval 60000

Tunables

AIX Tunables - Google "AIX Performance Management Guide"; Solaris Tunables - Google "Solaris 9 Tunables"; Linux Tuning Parameters - Google "Linux Tuning Parameters".

Optimize Your Database

Having a good database design always helps, but that may not be possible at times of performance testing. But still, understand how a database server works and know the tools that can help you monitor the transactions will be a big plus. One key metric to monitor is disk I/O (usually that is the bottleneck for a database). Disk I/O optimization is related directly to throughput and scalability. Access to even the fastest disk is orders of magnitude slower than memory access. Whenever possible, optimize the number of disk accesses. In general, selecting a larger block/buffer size for I/O reduces the number of disk accesses and might substantially increase throughput in a heavily loaded production environment.

Oracle

determine number of processes (how many concurrent users on the database server?) SELECT name, value FROM v$parameter WHERE name = 'processes';
Share pool size: SELECT * FROM v$sgastat WHERE name = 'free memory' AND pool = 'shared pool';
Other areas include Max opened cursor, database block size, and sort area size.

Microsoft SQL Server

Store tempdb on a fast I/O device (SAN device)
Increase the recovery internval if perfmon shows an increase in I/O.
Use an I/O block size larger than 2KB.

Identify the Best JVM Settings

Tune your JVM's heap garbage collection and heap size parameters to get the best performance out of your JVM. The Sun HotSpot and WebLogic JRockit JVM parameters that most significantly affect performance are listed below. For more detailed information, consult your JVM vendor's tuning documentation, as well as the JVM-related reading material at Java Virtual Machine (JVM) Information.

Sun JDK

When using the HotSpot VM option (-server or -client), experiment with the following garbage collection parameters:

    * -Xms and -Xmx (use equal settings at start up)
    * -XX:NewSize and -XX:MaxNewSize
    * -XX:SurvivorRatio
    * -XX:+UseISM -XX:+AggressiveHeap

For more information about tuning the HotSpot JVM, Google "JVM Heap Size and Garbage Collection".

JRockit JDK

When using JRockit's JVM, experiment with the following garbage collection parameters:

    * -Xms and -Xmx (use equal settings at startup)
    * -Xns
    * -Xgc: parallel
    * -XXenablefatspin

Monitor Disk and CPU Utilization

nmon is an excellent tool to report your system utilization including CPU and IO. See nmon page.

After following the previous steps, run your application under a high load while monitoring the:

* Application server (disk and CPU utilization)
* Database server (disk and CPU utilization)

To check your disk utilization on Solaris or Linux, use the iostat -D command,
where the interval value determines how many seconds you want to elapse between monitoring
cycles. To check your CPU utilization, simply leave off the -D flag (iostat ).

For Windows, use the Performance Monitor tool (perfmon), to monitor both your disk and CPU
utilization.

The goal is to get to a point where the application server becomes 100 percent utilized. If you
find that the application server CPU is not close to 100 percent, confirm whether the database
is bottlenecked. If the database CPU is 100 percent utilized, then check your application SQL
calls query plans. For example, are your SQL calls using indexes or doing linear searches? Also,
confirm whether there are too many ORDER BY clauses used in your application that are affecting
the database CPU.

If you discover that the database disk is the bottleneck (for example, if the disk is 100 percent
utilized), try moving to faster disks or to a RAID (redundant array of independent disks) configuration,
assuming the application is not doing more writes then required.

Once you know the database server is not the bottleneck, determine whether the application server
disk is the bottleneck. Some of the disk bottlenecks for application server disks are:

* JMS file store writes
* Transaction logging (tlogs)
* HTTP logging
* Server logging

The disk I/O on an application server can be optimized using faster disks or RAID, disabling
synchronous JMS writes, using JTA direct writes for tlogs, or increasing the HTTP log buffer.

Check out BEA documentation herepage.