While the question is a simple one, the answer itself is not. Every customer is unique including the physical topology, network topology, requirements, needs, and other application and hardware that make up the ecosystem. Performance tuning is a personalized exercise that is done uniquely with and for the customer. As mentioned several times, WPS and WESB are built on the core capabilities of the WebSphere Application Server infrastructure. Hence solutions built using WPS and WESB also benefit from tuning, configuration, and best practices information for WAS and the corresponding platform JVMs. However, having said this, here are some tips, considerations, and areas to look into for performance improvements:
Use Microflows wherever possible instead of long-running processes.
Use a high-performance disk subsystem.
Use DB2 instead of the default Derby DBMS. DB2 is a high-performing, industrial strength database designed to handle high levels of throughput and concurrency, scale well, and deliver excellent response time.
Disable tracing and monitoring; use this wisely.
Configure thread and connection pools to enable sufficient concurrency.
Avoid unnecessary usages of asynchronous invocations.
Use events (CBE) with judgment, since it uses a persistence mechanism.
BPC DB2 Database Tuning:
Avoid RUNSTATS on empty tables.
Separate the logfiles from the data, put them on their own volumes.
Large enough space allocation for logfiles and the log buffer.
Make the buffer pool big enough to avoid disk I/O.
Set only the monitor switches that are really needed to on.
Update optimizer statistics (RUNSTATS) to avoid deadlocks.
The throughput of the services you build on WPS and WESB will be limited by the external applications and services it will have to invoke which may have a lowest throughput capacity. Design your system taking into consideration these bottlenecks.
For large object (over 5 MB in general) processing consider batch patterns by splitting the large objects as multiple small objects.
Consider moving to a 64-bit mode (for server runtime) for applications that are well behaved and liveset exceeds 32-bit memory limitations.
Cache results of
ServiceManager.locateService()in your Java code.Use synchronous SCA bindings across local modules, since this binding has been optimized for module locality and will outperform other bindings.
Do not apply a QoS qualifier at the interface level if it is not needed for all operations of the interface.
When designing long-running business process components, ensure that callers of a two-way (request/response) interface do not use synchronous semantics, as this ties up the caller's resources (thread, transaction, and so on) until the process completes. Instead, such processes should either be invoked asynchronously, or through a one-way synchronous call, where no response is expected.
Minimize number and size of BPEL variables declared and business objects because each commit saves modified variables to the database.
The throughput is inversely related to the number of transaction boundaries traversed in the scenario, so fewer transactions are faster.
In an SCA assembly, we recommend using the SCA transactional qualifiers to reduce transaction boundaries. For any pair of components where this is desired, we recommend using the following golden path:
SuspendTransaction=false, for the calling component's referencejoinTransaction=true, for the called component's interfaceTransaction=any|global, for both components implementation
Components and modules can be wired to each other either synchronously or asynchronously. The choice of interaction style, especially choosing an asynchronous style, can have a profound impact on performance. Use asynchronous style only when needed. Set the preferred interaction style to Sync whenever possible.
Avoid asynchronous invocation of synchronous services in a fan-out/fan-in block.
There are three categories of Mediation primitives in WebSphere ESB that benefit to a greater or lesser degree from these internal optimizations:
Category 1 (greatest benefit):
Route on message header (message filter primitive)
XSLT primitive (transforming on /body as the root)
Endpoint Lookup without XPath user properties
Event emitter (CBE header only)
Category 2 (medium benefit):
Route on message body (message filter primitive)
Category 3 (lowest benefit):
XSLT and BO Maps—In a mediation flow that is eligible for deferred parsing, the XSLT primitive gives better performance than the BO Map primitive. However, in a mediation flow where the message is already being parsed, the BO Map primitive gives better performance than the XSLT primitive. Note that if you are transforming from the root (/), then the Business Object map will always perform better.
Do not run the production server in development mode or with development profile.
Do not use the UTE for performance measurement.
Use query tables to optimize query response time.
Place database logfiles on a fast disk subsystem.
WID performance considerations:
Opt for a faster and high speed disk drive
Defragment the drive periodically
Make use of shared libraries in order to reduce memory consumption