Embed Size (px)
Citation preview
Überleben im OSB / SOA Dschungel Daniel Joray Trivadis AG
Bern
Keywords
Weblogic, JMS, Performance, J2EE, Monitoring, SOA, OSB
Our SOA&OSB Project
Oracle SOA Suite is a comprehensive, standards-based software suite to build, deploy and manage
integration following the concepts of service-oriented architecture (SOA).
Oracle Service Bus is an enterprise service bus (ESB) that provides the key virtualization layer
required for any sustainable integration architecture.
In a productive environment a SOA-Suite infrastructure, involve many component. This is not always
easy to determine which component perform well and which not
Scope of this document is to give you some recommendations from our experiences, which we got in a
big customer case where all these components were involved. Installation
Use distinct middleware home for SOA and for OSB. (eliminate conflict in ORACLE_COMMON)
Use always the last patch Set Install your own JDK, don’t use the system JDK We have in this project better performance with Oracle JDK as with JRockit Install the last patch set and PSU in comparison with the base Version
o Patch 20423630: OSB Bundle Patch 11.1.1.7.4 fix 118 bugs o Patch 20900797: SOA Bundle Patch 11.1.1.7.8 fix 768 bugs o Patch 20780171: SU Patch [EJUW]: WLS PATCH SET UPDATE 10.3.6.0.12 fix
more than 700 bugs Nobody will spend time for upgrade in a project phase, but this is very important to plan
updates regularly in your project. Use a recent JDK compatible with Your middleware version After each patch regression testing must be done
WLS Domain Configuration
Create Your Domain in Production Mode mode to maximize performance. For performance testing and production environments, consider using the lowest acceptable
logging level, such as "ERROR" or "WARNING" whenever possible
Consider turning off the HTTP access logging If you use non-persistent JMS scenarios, explicitly turn off persistence at the JMS server level.
For persistent JMS scenarios you can use file store or JDBC store. If there are multiple JMS servers involved, create each store on a separate disk to lower I/O
contention. Tune the JVM Memory Configuration (Heap / Ration / algorithm) of each Managed Servers As sample the result in this project for the OSB part
o
Configure the Connection Pools for each Data Source o Ensure that the connection pool has enough free connections. o Set Initial Capacity and Minimum Capacity to the same value o Disable unnecessary connection testing and profiling o Enabling Data Source Statement Caching o Take care with the Option “Wrap datatypes” and DB Adapter o
Take a look to the Accept Backlog parameter (tune the number of connection requests that a WebLogic Server instance accepts before refusing additional requests)
Tune the Default Work Manager. It is used by an application when no other Work Managers are specified in the application’s deployment descriptors. The default work-manager belongs to a thread-pool, as initial thread-pool comes with only five threads, that's not much. If your application has to face a large number of hits, you may want to start with more than that.Well, that's quite easy.
For OSB you can create your own Work Manager in the WebLogic domain and assign them to
your services Force the time zone Set Configuration Archive Enable auf True and set the Archive Configuration parameter. This
will help you if you break your configuration If your system must be permanently available, it is best to define a cluster configuration type
from the beginning of your project SOA and OSB environments are extremely slow to start (several minutes) which makes them
unusable failover type configuration A cluster type of configuration is easily modified to accept more load depending on demand. For SOA and OSB cluster configurations are robust even under high load variation or if some
managed server are not available If you use mod_wl_ohs from the Oracle HTTP Server or mod_wl for Apache, set the
parameter WebLogic plugin Enabled to true
OSB Cluster If you deploy a large numbers of services in your OSB you can increase the size of the built-in
cache for proxy services
You can configure External Coherence Server and change the local-storage from each cache, if
you want no spend OSB JVM Memory for the cache. Check File osb-coherence-cache-config.xml and osb-coherence-override.xml located in $DOMAIN_HOME/config/osb/coherence/
You can enable result caching for the OSB Domain Chose witch method you will use for load balancing SOA Cluster Oracle SOA Suite 11g use an embedded Coherence cache to coordinate several cluster-wide activities including composite deployment. To allow the communication between the coherence cache membre you should add in the setDomain.sh/cmd those Properties In setDomain from Managed Server 1
In setDomain from Managed Server 2
Don’t forget to configure the Java Object Cache (JOC) and the post JMS configuration
and the post JMS configuration
In Enterprise console set
o The Audit Level property enables to Production
o Don’t forget to turn off the Payload Validation at SOA Infra Properties, if you don’t need validation at this level
o For the BPEL/BPMN Engine check the properties o dspSystemThreads o dspInvokeThreads o dspEngineThreads o largedocumentthreshold
o Mediator Engine check the properties o metricsLevel o Parallel Worker Threads (DeferredWorkerThreadCount) o Parellel Maximum Rows Retrieved (DeferredMaxRowsRetrieved) o Parallel Locker Thread Sleep (DeferredLockerThreadSleep)
SOA Schema
Don’t let your SOA Composite instance grow exponentially o Has one of the biggest impacts on a SOA business application o Impacts performance of runtime SQL queries o Impacts asynchronous routing rules and asynchronous BPEL processes o Slows down console access when querying for auditing data
Define rules to keep the house clean, purge the instances at regular interval to obtain better performance from BPEL engine and Enterprise Manager
Oracle provides a purge Script to delete instances that are no longer required using stored procedures that are provided with Oracle SOA Suite out of the box. (soa.delete_instance)
Testing
Performance optimization on SOA Suite applications is a challenge! A large number of components are involved in each Request Each component (JVM, DB, OSB, SOA, Network) must be initially optimized separately To ensure that parameter changes have the desired effect it is necessary to repeat the same test
under the same conditions several times (this change may have negative effects on the other part of the application)
To be representative test cases must represent reality End scenarios must be a representative mixture of all application services For each service it is necessary to develop automatic test scenario that can be repeated several
times. For each scenario it is necessary to define
o The expected response time o The number of times that this service can be called per second o The expected response
In reality, some query will be wrong, it is important that this type of queries is integrated into your test scenarios.
Many tool will test automation SoapUI, LoadUI, Jmeter, ect, the key is to master the one we chose!
Tools
For each component type there are many specific tools to perform these measurements o JVM -> jconsole, jvisualvm, jmc (Java Mission Control), DomainHealth WLST,
Enterprise Could Control, … o Domain -> DomainHealth, WLST, Enterprise Could Control, … o SOA -> DMS Spy, WLST, …
But only few tools give you the possibility to see your complete environment in the same a application (Enterprise Could Control, Dynatrace, AppDynamics)
Summary
Each components from a SOA Suite should be tuned separately. Do to this, you need automated test scenarios To tune an application, you must understand how it works, speak with developers To optimize the right parameters you need to understand what represents the measured
value The optimization application is a permanent job. it must be started from the start of
development
Contact:
Daniel Joray
Principal Consultant
Infrastructure Managed Services
trivadis ag
Weltpoststrasse 5
CH-3015 Bern
Mobile +41-79-320-17-39
www.trivadis.com
