8 min read

(For more resources related to this topic, see here.)

One of the main objectives of performance tuning is to achieve quick response time and more throughput. The application architect should work with business to understand the performance goals and set realistic performance expectations. The architect also needs to work with the infrastructure team to design the system’s infrastructure and configuration of SOA components based on the performance expectations. The performance tuning step assists us in identifying the optimal settings for infrastructure and application components.

We should know the current performance level and performance goals before tuning the system. The high-level plan for a performance tuning exercise for an application platform is as follows:

  • Document the performance/response time before making any changes also known as the baseline current performance

  • Document the configuration parameters for existing systems also known as the baseline current configurations

  • Document what is the expected end result and backup the entire system once
    and also at intermediate points during performance tuning

  • Document the performance benefits due to new values of the configuration
    parameter(s) and update the configuration and performance baselines with
    suggested values based on the Service Level Agreements (SLAs)

The Oracle SOA Suite is a couple of applications developed by Oracle using J2EE
technologies. One of the core applications is SOA-Infra, which is similar to any
other J2EE web application. The other major components of the SOA Suite are BPEL
Process, Mediator, Business Rules,
and Human Task. All the Oracle SOA Suite
components are deployed in a WebLogic server platform and also can deploy other
platforms such as WebSphere. There are separate tuning parameters available for
each of the Oracle SOA Suite applications and sub systems. Depending on your
SOA composite application’s deployment design one needs to holistically align
the configuration parameters of Oracle SOA Suite components in addition to the
WebLogic server platform, underlying Java Virtual Machine, Operating Systems,
and/or Load Balancers to get the optimal system performance.

Please note that by simply adding more hardware or increasing the hosting system’s
resources such as CPU and memory you may not improve the performance of an
application platform. The application design needs to be capable of utilizing these
additional resources for application performance and scalability benefits.

The Java Virtual Machine

The Java Virtual Machine (JVM) allows you to write programs once and run them
anywhere. Usually, JVMs are optimized for an operating system in combination with
the underlying hardware platform.

The leading JVM vendors are Sun HotSpot JVM and Oracle JRockit for Windows,
Unix, and Linux platform. Please note that Oracle is the vendor for both JRockit and
Sun HotSpot JVMs. The Sun HotSpot JVM is widely used and is the default choice
for Oracle SOA Suite implementations. Therefore, we will discuss the Oracle Sun
HotSpot JVM performance tuning in detail.

Garbage collection process

Garbage collection (GC) is a process of JVM that removes the unused Java
objects from the JVM heap to recycle the JVM resources. The configuration of the
underlying JVM for the WebLogic servers affects the Oracle BPEL Process Manager
performance. The details will be discussed in the following sections.

The Java heap memory space is divided into three sections: young, tenured, and
permanent generation, as shown in the following diagram. Minor garbage collection
occurs at the young generation space and major garbage collection occurs at the
tenured space.

Young generation

Young generation memory space is used whenever we create objects in Java. That
is why the young generation memory space is also known as new space. The Java
objects enter the young generation space and they either get the garbage collected
or move into the tenured generation space. Usually the young generation memory
space is smaller than the tenured generation space, therefore it has shorter collection
times as compared to the full GC in tenured space. The garbage collection process in
the young generation is known as Minor Garbage Collection (minorGC).

Tenured generation

The Java objects in the tenured generation space last longer than the young
generation space. Usually, the tenured generation memory space is bigger than
the young generation space and it takes more time as compared to minor garbage
collection occurring in the young generation. The garbage collection process in the
tenured generation is known as Major Garbage Collection (majorGC).

Permanent generation

Permanent generation holds the data needed by VM to describe objects (describing
classes and methods). It is recommended that we always allocate enough permanent
generation space to load Oracle SOA Suite library classes in a JVM. The default
permanent generation size is not sufficient for Oracle SOA Suite. There is no
garbage collection process in permanent generation space for a JVM.

Garbage collection tuning

The main objective of garbage collection tuning is to achieve less frequent garbage
collection with less pause time. Tuning the garbage collection process for a JVM is
very important because an application that spends about 10 percent of its time in
garbage collection can lose about 75 percent of its throughput when scaled out to
multiple processors.

In this section, we will learn the options to tune JVM to run the SOA Suite optimally.
The best way to tune the JVM and eliminate memory-related errors is to adjust JVM
memory parameters. The JVM parameters are usually part of the WebLogic server
start-up scripts. The default install values are not sufficient and may not provide an
optimal runtime performance for an Oracle SOA Suite implementation. You need to
ensure that the default JVM parameters are updated. The recommended heap size
for Oracle SOA Suite is 4 GB. Some of the major JVM parameters for JDK 6 are
as follows:

code1

During performance tuning, it is important to ensure that all endpoint
applications are responding properly. When you adjust the minimum and
maximum heap parameters, please ensure that you adjust the other parameters
as well. The PermSize parameter can be constant but the NewSize and
MaxNewSize parameters require tuning.

It is recommended for better performance that we keep the same values for following
pairs for JVM parameters:

  • Minimum heap size (-Xms) and maximum heap size (-Xmx)

  • -XX:PermSize and -XX:MaxPermSize

  • -XX:NewSize and -XX:MaxNewSize

Choosing the garbage collection algorithm

One of the key JVM parameters is the choice of the garbage collectors. Two of the
major garbage collectors are listed as follows for reference:

  • Mark and sweep (-XX:+UseConcMarkSweepGC)

    Mark and sweep garbage collection algorithm minimizes the garbage
    collection pause time that enables us to avoid impacting the production
    transaction during the GC process. This algorithm will run the tenured
    generation concurrently with the execution of the application.

  • Throughput collector parallel collector (XX:+UseParallelGC)

    That throughput collector distributes the garbage collection load across
    CPUs; therefore maximizing throughput.

    It is ideal for using with multiprocessor machines usually with four or
    more processors.

Select NewSize

Set -XX:NewSize to be one-fourth of the size of the maximum heap size. The larger
the young generation space means smaller the tenured space. One can’t specify
the tenured generation size directly; the size of the tenured generation space is
determined by the total heap size and NewSize.

code1

The higher values of NewSize will result in a lesser minor garbage collection.

To verify the JVM performance, use Oracle SOA Suite Enterprise Manager
Console. Select the WebLogic domain and use the JVM performance to view
the performance details.

The other available options are to use the WebLogic Console or JVisualVM.

Select heap size

Set the values of -Xms and -Xmx to around 80 percent of the available physical
memory on a server. The remaining 20 percent memory is left for the operating
system and other processes. Setting the value of -Xmx to a very high value will result
in a slower majorGC that occurs less frequently. Setting too high values for a JVM
heap size can cause wasted memory and performance impact during a majorGC.
Please note that on a 32-bit OS server(s) a JVM can only use a maximum 2.5 GB.

Garbage collection tool – JVisualVM

JVisualVM is a GUI-based JVM monitoring, troubleshooting, and profiling tool
that can be used to diagnose JVM performance, JVM garbage collection processes
to tune JVM parameters for an application platform such as Oracle SOA Suite. The
JVisualVM tool is part of JDK Version 6 that combines several JVM utilities such as
JConsole, jstat, jinfo, jstack, and jmap under one roof.

To start the JVisualVM, go to the bin directory of the JDK install and invoke
the jvisualvm application. The Java Visual VM tool provides a view of all
the Java parameters set for a WebLogic server environment, as shown in the
following screenshot:

Using the JVisualVM tool one can see the live CPU usage, GC activity, and
Heap activity for an application such as Oracle SOA Suite, as shown in the
following screenshot:

You can also view the JVM performance details for the garbage collection activity by
adding the following parameters as part of the WebLogic start-up scripts:

  • –XX:+PrintGC: Outputs the basic information at every garbage collection

  • –XX:+PrintGCDetails: Provides the size of live objects before and after
    garbage collection for the various generations, the total available space for
    each generation, and the length of time the collection took

  • –XX:+PrintGCTimeStamps: Provides a timestamp at the start of each collection
    that helps us correlate garbage collection logs with other logged events

  • –XX:+PrintGCTimeStamps: Provides a timestamp at the start of each collection
    that helps us correlate garbage collection logs with other logged events

You are recommended to create a table with JVM parameters and its impact on
the performance during the tuning process, as shown in the following table using
excel or word. In the tuning process always analyze GC activities for pause time,
frequency, and average memory footprint.

LEAVE A REPLY

Please enter your comment!
Please enter your name here