44,39 €
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.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 357
Veröffentlichungsjahr: 2013
Copyright © 2013 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: July 2013
Production Reference: 1040713
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-84968-884-0
www.packtpub.com
Cover Image by Abhishek Pandey (<[email protected]>)
Authors
Matt Brasier
Nicholas Wright
Reviewers
Sandeep Phukan
Sylvain GROSJEAN
Tumelo Mametsa
Acquisition Editors
Grant Mizen
Antony Lowe
Lead Technical Editor
Susmita Panda
Technical Editors
Pushpak Poddar
Rikita Poojari
Lubna Shaikh
Project Coordinators
Abhishek Kori
Wendell Palmer
Proofreaders
Elinor Perry Smith
Stephen Silk
Indexer
Hemangini Bari
Graphics
Valentina D'silva
Abhinash Sahu
Production Coordinator
Conidon Miranda
Cover Work
Conidon Miranda
Matt Brasier is a professional services consultant with 10 years of experience tuning Enterprise Java applications. He has 9 years of experience working with Enterprise Java middleware, and has always focused on the performance aspects of application servers and SOA platforms. Matt has spoken at numerous technical conferences, including The Serverside Java Symposium and JUDCon.
Matt is the head of consulting at C2B2 Consulting Ltd., an independent middleware consultancy specializing in SOA and JEE, providing professional services on the leading Java middleware platforms. C2B2 is an Oracle Gold Partner with Application Grid Specialization.
I would like to thank my partner, Caroline, and our dog, Minstrel, for their understanding while I was writing this book, my father for encouraging me at the start, and C2B2 for giving me the time and experience necessary to do it.
Nicholas Wright is a Java middleware consultant and technical evangelist with 9 years of experience from Embedded C real-time systems to Enterprise Java. He has served on a Java Community Process Expert Group, and spoken at conferences across the world.
Nick is a senior consultant at C2B2 Consulting Ltd., where he works with a wide range of commercial and open source JEE and SOA middleware platforms.
I would like to thank my family, friends, and colleagues for whom I have disappeared off the face of the Earth while working on this book. For your patience and understanding, I thank you. Mostly I must thank my partner, Kay Louise, for putting up with my continual slaving over a computer whenever I have any spare time, love you.
Sandeep Phukan has more than 9 years of experience in Integration Technologies and Java. Sandeep currently works as a Senior Consultant with Anatas Technology Services, Sydney, a leader in next generation Enterprise Architecture Solutions. Earlier, Sandeep worked as a Technical Lead for Nokia Siemens Network R&D, Bangalore, assisting on the integration of Next Generation Unified Convergent Billing Systems based on Oracle Fusion Middleware 11g.
Prior to this, Sandeep worked with Oracle SSI, Bangalore as a Senior Consultant, where his key involvement was Oracle AIA for Communications (Telco PIP). During this period he travelled to several countries around the world, aiding customers in developing customizations for Oracle AIA artifacts.
Sandeep is a certified Java Developer and has a keen interest in Low Bandwidth Transports and Distributed Algorithms. During his time at Oracle SSI, Sandeep was actively involved with the SSI Innovation Centre where he created a number of utility extensions to the Oracle SOA Suite. Sandeep also maintains an open source repository of several SOA utilities in the Google code repository http://code.google.com/p/soalabs/.
Sandeep is also an avid researcher in the area of SOA Governance. He has published a number of papers in the Oracle Technology Network (OTN) on technology neutral Designtime Dependency analysis of SOA Artifacts. One of his inventions on this subject (Graph Based Designtime Dependency Analysis) has recently been accepted for a Patent in the US Patents and Trademarks Office (USPTO).
I would like to thank my loving wife Aparupa for her patience during those late night researches, and my friends and colleagues at Anatas who were always there whenever I needed them.
Sylvain GROSJEAN is a principal Oracle Fusion Middleware consultant currently working as a freelancer in France.
Over the past 12 years, he collaborated with BEA, and then with Oracle Consulting as a solution architect and trainer helping multiple major French clients (Utilities, Transportation, Insurance, Healthcare, Telecom).
His primary focus is on Oracle Service Bus, Oracle SOA Suite, Oracle BPM, and ADF.
You can follow Sylvain through his own blog at http://sgrosjean.blogspot.com
Tumelo Mametsa is an Oracle Fusion Middleware expert currently consulting on various projects in South Africa and other African countries. He has over 10 years of experience in the Electronics and IT fields, respectively, with increasing level of responsibility. He is currently providing senior leadership for solutions architecture, enterprise architecture, business process engineering efforts, including SOA and Open Source Solutions for Africom IT Solutions.
His focus is on engineered systems using various technologies, primarily the Oracle Fusion Middleware Stack. He also provides training for Oracle on Oracle Fusion Middleware Products.
To my extended, supportive, loving Mametsa family (Mpho, Stlaks, Tshepo, Nunu, Letsie, Gontse), thanks for always being there for me. Much love to my darling wife Tsakani and kids, Tumisa, and Seetja. You guys make everything worthwhile. Thanks to my partners at Africom IT Solutions, you are the best team to work with by far. Much appreciation to all my friends (the Zoo) for individually supporting me in your unique ways, without you guys I would not be able to expertly juggle so many balls.
You might want to visit www.PacktPub.com for support files and downloads related to your book.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at <[email protected]> for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
http://PacktLib.PacktPub.com
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can access, read and search across Packt's entire library of books.
If you have an account with Packt at www.PacktPub.com, you can use this to access PacktLib today and view nine entirely free books. Simply use your login credentials for immediate access.
Get notified! Find out when new books are published by following @PacktEnterprise on Twitter, or the Packt Enterprise Facebook page.
Oracle SOA Suite 11g forms the basis of the SOA infrastructure for many organizations. While there is a wealth of information on administering SOA Suite applications already available, there is very little independent information available regarding performance tuning. With the chief goal of software and hardware vendors being to sell more licenses and hardware, the topic of getting the most from your existing investment often falls by the wayside. This book aims to address that by giving clear, concise, and simple recipes that will help you identify performance bottlenecks in your application, and then resolve them.
We work from the ground up, starting with how to identify common SOA Suite 11g performance problems and introducing the tools that you need, and working up the stack through JVM tuning and application server tuning, before covering the BPEL, BPMN, and mediator stacks. Finally, we have chapters on application design and deployment considerations.
Chapter 1, Identifying Problems, starts out by looking at some of the common performance problems that can occur in the Oracle SOA Suite applications, and how to identify them. We look at using a variety of tools to understand what is going on inside the JVM, and to identify the particular resource bottleneck that is causing poor performance.
Chapter 2, Monitoring Oracle SOA Suite, looks at how we can use the VFabric Hyperic tool from VMWare to monitor the performance of our SOA Suite infrastructure, and what metrics we should be keeping an eye on.
Chapter 3, Performance Testing, looks at using the Apache JMeter tool to solve performance problems, by triggering them.
Chapter 4, JVM Memory, starts right at the bottom of the Oracle SOA Suite 11g stack. We look at how JVM memory is allocated, and how you can increase and decrease the memory available to your application, as well as other JVM tuning tips. The low-level areas of Oracle SOA Suite are often overlooked, so we cover the basics of Java memory management in enough detail to give those unfamiliar with it sufficient background to understand what they need to be concerned about.
Chapter 5, JVM Garbage Collection Tuning, teaches us how the Java virtual machine garbage collector does a very complicated job, and that there are a number of ways of optimizing it for the kinds of payloads that Oracle SOA Suite 11g usually has to handle.
Chapter 6, Platform Tuning, looks at some of the tuning options available in the operating system and Oracle WebLogic server that can improve the performance of SOA Suite 11g applications.
Chapter 7, Datasources and JMS, covers tips related to JMS and Datasource tuning that can improve the performance of resource-intensive SOA Suite applications.
Chapter 8, BPEL and BPMN Engine Tuning, primarily focuses on how we can improve the performance of the engine itself, including database tuning recipes, and helps those who find that the bottleneck of their SOA Suite system is the BPEL or BPMN application itself.
Chapter 9, Mediator and BAM, focuses on tuning the Oracle SOA Suite Mediator, and also includes some information on tuning the BAM Adapter for SOA Suite application that connects to a BAM service.
Chapter 10, Rules and Human Workflow, focuses on tuning the rules and human-workflow components, and our recipes focus on how to reduce resource contention.
Chapter 11, SOA Application Design, focuses on design-time recipes that will be of more interest to architects. We also discuss how design-time decisions can have an impact on the performance of a SOA Suite application, and covers best practices for designing the key components.
Chapter 12, High Performance Configuration, takes a higher-level look at the Oracle SOA Suite-deployment architectures, focusing on how we can use cluster and load balance to scale our application out to meet performance requirements.
We obviously assume that you have an Oracle SOA Suite 11g application, and are looking to tune it. So we expect that you have the necessary software and licenses from Oracle. In addition to SOA Suite 11g from Oracle, which is used throughout the book, we also make use of the VFabric Hyperic HQ monitoring tool from VMWare, and the JMeter load-testing tool from Apache. Both Hyperic and JMeter are freely available from their respective vendors.
The target audience for this book are Oracle SOA Suite administrators of all levels of experience. Whether you normally administer databases and have had SOA Suite handed to you because it has Oracle in the name, or whether you have years of experience in SOA administration, we are sure you will find something useful in this book. While the primary audience are the administrators, there is plenty of useful information—to think about when designing applications—for application architects as well.
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "Batching_Limit_Lower determines the minimum number of messages in the batch."
A block of code is set as follows:
Any command-line input or output is written as follows:
New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this:
"Set the property Metrics Level to Disabled."
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an e-mail to <[email protected]>, and mention the book title via the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
You can download the example code files for all Packt books you have purchased from your account at http://www.PacktPub.com. If you purchased this book elsewhere, you can visit http://www.PacktPub.com/support and register to have the files e-mailed directly to you.
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the erratasubmissionform link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
You can contact us at <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.
This chapter looks at some of the tools and techniques that you can use to identify the areas where any performance bottlenecks are in your SOA Suite application. It covers the following recipes:
When asked to look into performance issues with a SOA Suite installation, we commonly start by collecting log files from the various system components, looking for clues on any errors or points of contention. The more advanced among us may even have collected Java garbage collection logs and runtime data, and then reviewed it for the same reasons. We encourage these actions as a starting point, but what do we do when the information isn't available in log files? The goal of this chapter is to bridge the gap between knowing there's an issue and identifying it, by introducing a range of tools and techniques for looking at scenarios, before thinking about how to take a remedial action.
The remainder of this book contains a number of recipes that will help you improve the performance of your SOA Suite application by tuning various aspects of the infrastructure, but the changes will generally only make a difference in the area in which the application is slow.
The first step in being able to performance tune your SOA Suite application is to be able to identify where the performance bottlenecks are. Performance is always governed by the availability of resources, and there is always some bottleneck in an application, which prevents it from performing faster. These resources can include the following:
Memory is not generally a significant bottleneck on its own, but not having enough memory available to your SOA Suite application results in excessive Java garbage collection, which is a CPU-intensive activity, resulting in contention on the CPU. The most common bottlenecks in SOA Suite applications are IO time (waiting for data to be written to some resource, such as a disk or the network) and availability of data (waiting for data to be provided by some external system or user). However, all of the resources mentioned in the preceding list can cause bottlenecks in a SOA Suite application.
It is worth noting that different use cases can have different bottlenecks, so you need to tune for a realistic set of use cases; this is something that is discussed in more detail in a later performance tuning chapter.
We'll start by looking at some tools bundled in the various SOA Suite Java Virtual Machines for diagnosing Java issues, and look at some other common causes of resource contention in SOA Suite. The recipes in this chapter offer suggestions on next steps for common issues, but as mentioned earlier, later chapters will target specific areas of the SOA infrastructure in more detail, once you get over the hurdle of knowing where to start looking.
jstatis 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.
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.
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:
Use the jstat command to view the sizes of the survivor spaces and Eden: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.
Check that S0C and S1C have values of 10000 or higher.Check that EC has a size of between 20 percent and 50 percent of OC.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.
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.
The permanent generation is a special part of the HotSpot JVM's memory, which stores "class templates"' for the JVM class loader to use when creating and removing objects.
jstat is a JVM command-line tool, which shows you a number of statistics regarding how the JVM is performing.
In this recipe, we use jstat to understand the size of the permanent generation.
You will need SOA Suite installed for this recipe, and will need permission to execute the domain control scripts, as well as the HotSpot JVM tools. This recipe assumes that your SOA Suite application is running such that we may run jstat against it.
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.
This recipe assumes you are using HotSpot, as JRockit does not have a permanent generation.
The metrics we are interested in are PC and PU. PC is the capacity (size) of the permanent generation (in KB), and PU is the utilization of the permanent generation (in KB).
We want to see that PU is around 80 percent or less of PC.jstat is a JVM tool that can be used to view a number of runtime statistics regarding the JVM. The option –gc printsthe 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).
Permanent generation is the section of JVM memory that is used to store classes and other objects that cannot be represented as Java types. The larger a SOA Suite application is, the more classes it will contain, and the more permanent generation it will need. If the permanent generation is too small, classes will need to be unloaded and reloaded in the permanent generation, causing full garbage collections to occur, and a performance hit. We want permanent generation to be large enough to hold all the classes in your SOA Suite application, with a little overhead for other resources, so if the utilization of the permanent generation is around 80 percent of its capacity, we should have sufficient overhead to prevent classes needing to be unloaded.
jstat is a JVM command-line tool, which shows you a number of statistics regarding how the JVM is performing. In this recipe, we use jstat to understand the size of the permanent generation.
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.
This recipe assumes you are using HotSpot, as JRockit does not have a permanent generation.
The metrics we are interested in are YGCC, YGCT, FGCC, and FGCT. These are the young garbage collection count, young garbage collection time, full garbage collection count, and full garbage collection time.
jstat is a JVM tool that can be used to view a number of runtime statistics regarding the JVM. The option –gc prints 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).
Since garbage collection is a "stop the world" activity, any time spent garbage collecting is not the time spent in executing your business logic. We therefore want to minimize the amount of time spent in performing garbage collection. See the chapter on garbage collection for more details on what we are looking to achieve with garbage collection tuning.
In Chapter 5, JVM Garbage Collection Tuning, we also pass the JVM a startup option to enable verbose GC logging output, so we can capture this data all the time.
We can then run free tools such as GCviewer (http://www.tagtraum.com/gcviewer.html) on this data output to visualize the data trends. Later in this chapter, we will introduce using real-time monitoring tools bundled with the JVM to view this same data.
As SOA Suite is a heavily multi-threaded Java application, where locks are used to synchronize resources. If the threads encounter issues sharing these locks, then the impact on performance can be severe.
jstack is a HotSpot JVM tool that allows you to view thread dumps, which can be a useful way of identifying locking problems in your application.
You will need 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, and under a normal load.
The tools jps and jstack are included with the HotSpot JVM. If you're using JRockit, then see the There's more.. section of this recipe for the alternative command to use. For brevity, this recipe assumes that you have the relevant JVM bin directory on your command line path. If you do not, simply use the fully qualified paths to the relevant bin directory.
This will generate a file called jstack-output.txt. Alternatively kill -3 <pid> can be used on Linux or Ctrl + Break in the console in Windows.
Open jstack-output.txt in your favorite text editor. There are two main types of locking problem we are looking for. The first is a deadlock, where two threads each own one or more locks, but are both waiting on each other's locks. This will look something similar to the following screenshot:Note that each thread is waiting on the lock held by the other thread. If you see thread deadlocks, this generally requires that you redesign your application to acquire locks in the correct order.
The second type of problem we are looking for is lock contention. This occurs when many threads are all waiting to get access to the same lock. When this occurs, you will see many threads all waiting on the same lock. This usually also requires application code changes to resolve.
The jstack tool comes with the HotSpot JVM, and is used to
