Book Image

Oracle SOA Suite 11g Performance Tuning Cookbook

Book Image

Oracle SOA Suite 11g Performance Tuning Cookbook

Overview of this book

Oracle SOA Suite 11g forms the heart of many organisations' Service Oriented Architecture. Yet for such a core component, simple information on how to tune and configure SOA Suite and its infrastructure is hard to find. Because Oracle SOA Suite 11g builds on top of a variety of infrastructure components, up until now there has been no one single complete reference that brings together all the best practices for tuning the whole SOA stack. Oracle SOA Suite 11g Performance Tuning Cookbook contains plenty of tips and tricks to help you get the best performance from your SOA Suite infrastructure. From monitoring your environment so you know where bottlenecks are, to tuning the Java Virtual Machine, WebLogic Application Server, and BPEL and BPMN mediator engines, this book will give you the techniques you need in a easy to follow step-by-step guide. Starting with how to identify problems, and building on that with sections on monitoring, testing, and tuning, the recipes in this book will take you through many of the options available for performance tuning your application. There are many considerations to make when trying to get the best performance out of the Oracle SOA Suite platform. This performance Cookbook will teach you the whole process of tuning JVM garbage collection and memory, tuning BPEL and BPMN persistence settings, and tuning the application server. This book focuses on bringing together tips on how to identify the key bottlenecks in the whole SOA Suite infrastructure, and how to alleviate them. The Oracle SOA Suite 11g Performance Tuning Cookbook will ensure that you have the tools and techniques to get the most out of your infrastructure, delivering reliable, fast, and scalable services to your enterprise.
Table of Contents (19 chapters)
Oracle SOA Suite Performance Tuning Cookbook
Credits
About the Authors
About the Reviewers
www.PacktPub.com
Preface
Index

Identifying new size problems with jstat


jstat is a Java Virtual Machine (JVM) command-line tool, which shows you a number of statistics regarding how the JVM is performing. In this recipe, we will use it to understand how large the new size is, and how frequently it is filling up.

Getting ready

You will need the SOA Suite installed for this recipe, and will need permission to execute the domain control scripts, as well as the JVM tools. This recipe assumes that your SOA Suite application is running under a normal load.

The tools jps and jstat are included with both the HotSpot and JRockit JVMs. For brevity, this recipe assumes that you have the relevant bin directory on your path. If you do not, simply use the fully qualified paths to the relevant bin directory.

How to do it…

  1. Use JPS to determine the process ID of your SOA Suite server.

    jps –v

    The process ID is the number in the first column. The SOA Suite server can be identified by the command-line options that the JVM has. If you have multiple SOA Suite servers running on the same machine, you can identify the relevant server by the –Dweblogic.Name parameter, as shown in the following screenshot:

  2. Use the jstat command to view the sizes of the survivor spaces and Eden:

    jstat -gc -h10 <pid> 2000

    The metrics we are interested in are S0C, S1C, EC, and OC. These are the sizes (capacity) of the two survivor spaces, the Eden space and the old generation, all in KB.

  3. Check that S0C and S1C have values of 10000 or higher.

  4. Check that EC has a size of between 20 percent and 50 percent of OC.

How it works…

jstat is a JVM tool that can be used to view a number of runtime statistics regarding the JVM. More detail on the JVM and its memory layouts is available in the recipes in Chapter 5, JVM Garbage Collection Tuning. The option -gc prints the statistics about garbage collection, including the capacity and utilization of each memory pool. In the preceding example, the parameter –h10 prints the headers every 10 lines, to make the output easier to read, and 2000 is the time in milliseconds between each sample (2 seconds).

What we are looking for are problems caused by the new generation memory spaces (Eden and the two survivor spaces) having capacities that are too small. This will cause garbage collection to occur more frequently than necessary, resulting in poor performance. Due to their nature, SOA Suite applications usually involve a lot of object allocation, but many of these objects generally do not last very long (the duration of a request), so they can be collected while they are still in the Eden or one of the survivor spaces. For this reason, we generally want a SOA Suite application to have an Eden size that is between 10 percent to 33 percent of the total heap size. From our experience, this is a good starting point for an Eden space that needs to cope with lots of short-lived objects. The survivor spaces should be large enough to hold the objects generated by one or two large requests, and we have found that values smaller than 10 MB (around 10000 in jstat) can cause problems.

There's more…

If you have set the new size (or new ratio) and survivor ratio values on the command line, then the values you see in the output of jstat should match those you specified.

See also

  • The Setting the survivor ratio and Setting the JVM new size recipe in Chapter 5, JVM Garbage Collection Tuning