WebLogic Server Performance and Tuning
Performance tuning WebLogic Server and your WebLogic Server application is a complex and iterative process. To get you started, we have created a "top ten" list of recommendations to help you optimize your application's performance. These tuning techniques are applicable to nearly all WebLogic applications. Although we highly recommend performing these tasks in the sequence they are presented, this isn't a requirement.
Gather information about the level of activity expected on your server, the anticipated number of users, the number of requests, acceptable response time, and an optimal hardware configuration (e.g., fast CPU, disk size vs. speed, sufficient memory, and so on.).
There is no single formula for determining your hardware requirements. The process of determining what type of hardware and software configuration is required to meet application needs adequately is called capacity planning. Capacity planning requires assessment of your system performance goals and an understanding of your application. Capacity planning for server hardware should focus on maximum performance requirements.
For more information about capacity planing for WebLogic Server, see the BEA WebLogic Server Capacity Planning Guide.
Each operating system sets default tuning parameters differently. For Windows platforms, the default settings are usually sufficient. However, the UNIX and Linux operating systems usually need to be tuned appropriately.
Use the following guidelines when tuning UNIX operating systems supported by WebLogic Server.
For better TCP (transmission control protocol) socket performance, set the tcp_time_wait_interval
parameter as follows:
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.
Note: Prior to Solaris 2.7, the tcp_time_wait_interval
parameter was called tcp_close_wait_interval
.
For additional recommended Solaris tunable settings, see:
For more information about Solaris tuning options, see:
For HP-UX tuning information, see:
See the AIX 5L Version 5.2 Performance Management Guide.
For better packet transfer performance, set the /sbin/ifconfig lo mtu
parameter as follows:
The mtu
(maximum transfer unit) parameter refers to largest number of bytes that a packet can carry over the network. If the packet size is set too low, then your network performance will decrease due to fragmented data.
For additional recommended Linux tunable settings for WebLogic Server, see Linux Tuning Parameters. For general information about Linux tuning, consult your Linux vendor's documentation. Also, the Ipsysctl Tutorial 1.0.4 describes all of the IP options provided by Linux.
For Windows platforms, the default settings are usually sufficient. For more information about Windows 2000 tuning options, see:
Your database can be a major enterprise-level bottleneck. Configure your database for optimal performance by following the tuning guidelines in this section and in the product documentation for the database you are using.
Here are some general database tuning suggestions:
Here are some basic tuning suggestions for Oracle, SQL Server, and Sybase. Again, you should also check the tuning guidelines in your database-specific vendor documentation.
This section describes performance tuning for Oracle 8.1.7.
SELECT name, value FROM v$parameter WHERE name = 'processes';
For most applications, the shared pool size is critical to Oracle performance. If the shared pool is too small, the server must dedicate resources to managing the limited amount of available space. This consumes CPU resources and causes contention because Oracle imposes restrictions on the parallel management of the various caches. The more you use triggers and stored procedures, the larger the shared pool must be. The SHARED_POOL_SIZE
initialization parameter specifies the size of the shared pool in bytes.
The following query monitors the amount of free memory in the share pool:
SELECT * FROM v$sgastat
WHERE name = 'free memory' AND pool = 'shared pool';
OPEN_CURSORS
initialization parameter allows administrators to limit the maximum number of opened cursors for each connection. Unfortunately, the default value for this parameter is too small for systems such as WebLogic Server. Cursor information can be monitored using the following query:SELECT name, value FROM v$sysstat
WHERE name LIKE 'opened cursor%';
SELECT name, value FROM v$parameter WHERE name = 'db_block_size';
init.ora
parameter is usually the size of 6-8 data blocks. This value is usually sufficient for OLTP operations but should be increased for decision support operation, large bulk operations, or large index-related operations (for example, recreating an index). When performing these types of operations, you should tune the following init.ora
parameters (which are currently set for 8K data blocks):sort_area_size = 65536
sort_area_retained_size = 65536
The following guidelines pertain to performance tuning parameters for Microsoft SQL Server databases. For more information about these parameters, see your Microsoft SQL Server documentation.
tempdb
on a fast I/O device.perfmon
shows an increase in I/O.The following guidelines pertain to performance tuning parameters for Sybase databases. For more information about these parameters, see your Sybase documentation.
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.
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, see JVM Heap Size and Garbage Collection.
When using JRockit's JVM, experiment with the following garbage collection parameters:
Also, see WebLogic JRockit Documentation.
The WebLogic Server configuration file (config.xml
) contains a number of OOTB (out-of-the-box) performance-related parameters that can be fine-tuned depending on your environment and applications. Tuning these parameters based on your system requirements (rather than running with default settings) can greatly improve both single-node performance and the scalability characteristics of an application.
Try experimenting with the following WebLogic Server configuration tuning parameters to determine your system's "sweet spot" for optimal performance:
NativeIOEnabled=true
), as described in Using WebLogic Server "Native IO" Performance Packs.JSP
compilation, javac
, which is significantly slower than jikes
or sj
, as described in Setting Your Java Compiler.
After following the previous steps, run your application under a high load while monitoring the:
To check your disk utilization on Solaris or Linux, use the iostat -D <
interval>
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 <
interval>
).
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:
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 the amount of data transferred between the application and the application server, and between the application server and the database server. This amount should not exceed your network bandwidth; otherwise, your network becomes the bottleneck. To verify this, monitor the network statistics for retransmission and duplicate packets. This can be done using the following command:
For instructions on viewing other TCP parameters using the netstat -s -P
command, see Setting TCP Parameters With the ndd Command.
Make sure your application is not doing too much standard I/O or excessive logging. Either situation could significantly slow system performance. In production environments, remove all system.out.println
statements from your code, as these statements should only be used in development environments for debugging purposes.
If you determine that neither the network nor the database server is the bottleneck, start looking at your WebLogic Server applications. Most importantly, is the machine running WebLogic Server able to get 100 percent CPU utilization with a high client load? If the answer is no, then check if there is any locking taking place in the application. You should profile your application using a commercially available tool (for example, JProbe or OptimizeIt) to pinpoint bottlenecks and improve application performance.
Tip: Even if you find that the CPU is 100 percent utilized, you should profile your application for performance improvements.
For more information about application profiling tools, see Using Performance Analysis Tools.
This section contains recommended application-specific tuning suggestions for performance improvement.
See Tuning WebLogic Server EJBs.
See "Introduction to Programming" in Programming WebLogic HTTP Servlets.
onMessage
) JMS consumers instead of synchronous receivers.See the "WebLogic JMS Performance Guide" white paper on BEA dev2dev. For administrative tuning guidelines, see "JMS Tuning" in the Administration Console Online Help.
See How JDBC Connection Pools Enhance Performance and "Performance Tuning Your JDBC Application" in Programming WebLogic JDBC.