Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

 

 

 

Normal 0 false false false EN-US X-NONE X-NONE

 

 

 

Normal 0 false false false EN-US X-NONE X-NONE

 

 

 

Normal 0 false false false EN-US X-NONE X-NONE

 

There is no standard approach one should follow while implementing Performance Tuning at their landscape. Here I am just trying to list out a approach, if anyone think that i would be missing something please comment it out.

 

We can improve webMethods performance by tuning various components: MWS, Broker Server, TN, Integration Server, Optimize.. etc. Apart from this you have to look into other aspects like Architecture, Hardware, Target systems, Database, Operating system, Backend system etc..The below approach is defined taking webMethods  version(6.1) as standard.

 

 

 

Normal 0 false false false EN-US X-NONE X-NONE

 

1. Architecture:

 

ü Place components close together if they communicate frequently. This is fairly obvious, but it cannot be stated too often. Networks can very easily become the performance bottleneck in an integration project. Properties database and logging F/S or database should be closer. The most complex interactions in integration projects usually occur between an Adapter and the resource it is adapting. Minimizing the network distance between the Adapter and the resource can be extremely important for performance because it minimizes communications across the network.

 

ü Commonly-invoked services can be identified using the Integration Server’s service usage statistics in the Administrator. Use this in conjunction with audit logs to determine which services to target during performance tuning.

 

ü If you can measure processing one “item” at a time, try to identify whether the average processing time gets worse and worse as time goes on. For instance, you might have 100 items (all about the same size) and each of the first 20 takes 200ms each, then each one successively takes more and more time until the last 10 take 600ms each. This might be an indication of inefficiencies in your implementation, a cluttered pipeline for instance. If you do detect this situation, use enable/disable step to try to simplify the processing so that each of the 100 items takes the same amount of time, and then methodically add back the functionality to discover the code that exhibits the non-linear time

 

ü When using the WmDB or WmJDBC adapter often the performance throughput will be dictated by the performance of the Database.

 

ü Install all performance-related patches and service packs.

 

ü Turn off all non-essential listeners (e.g. ftp, email).

 

ü SSL can cause a significant performance hit. In some cases, we have seen the introduction of SSL increase processing time by roughly 2 to 5 times. Consider the use of a Hardware SSL accelerator (e.g. nCipher™) to improve SSL performance.

 

Performance Considerations knowing the Characteristics of Your Solution

 

ü webMethods Broker and webMethods Integration Server interact using a high-speed wire protocol. But the speed at which these two components exchange documents is ultimately determined by resource availability (memory, threads, CPU cycles and so forth) and the characteristics of your solution (for example, guaranteed or volatile documents, serial or parallel processing).

 

ü You can use the information in this document more effectively if you understand the following characteristics of your solution:

 

― Average document size

 

― Maximum document size

 

― Average document arrival rate

 

― Peak document arrival rate

 

― Average document processing time (by subscriber)

 

― Expected demand cycles (recurring intervals of high or low demand)

 

― Use of guaranteed versus volatile documents

 

― Number of active triggers on the Integration Server

 

― Number of trigger execution threads on the Integration Server

 

― Volume of audit events

 

― Overall performance of audit database

 

― Number of concurrent connections allowed by audit database system

 

ü Understanding these characteristics allow you to anticipate resource usage at various points of a pub/sub integration and provides essential information for capacity planning efforts. For example, knowing the average document size and arrival rate will help you estimate the amount of memory your Broker and Integration Server need under ‘ordinary’ operating conditions.

 

ü Similarly, understanding your peak values can help you decide whether one platform configuration will support your maximum requirements better than another. For example, it can help you determine whether you should install certain components on the same machine, or whether, under peak loads, these components would perform better if you installed them on separate machines.

 

ü The more you understand the characteristics and requirements of your solution, the more successful your tuning efforts will be.

 

ü Scalability

 

Scalability is the ability of a system to handle increased load.Scaling the webMethods Integration Platform can help to improve the performance of the solution. Using webMethods, scalability can be achieved in two primary manners:

 

ü Vertical Scaling – Ability to increase the power of a particular resource to support higher capacity – for example adding CPUs, RAM, cache, and disks to a server. Vertical scaling offers quick solutions to many scalability issues, but the diminishing law of returns means that there is always a level at which simply adding more bits to a box has very little effect.

 

ü Integration Server 6.0.1 with SP2 can achieve a scalability factors of 1.6 to 1.9 when going from a single to dual processor system averaging approximately 1.7 for the XML transformation test. The scalability factor for four processors ranged from 2.8 to 3.0 with an average value of 2.9.

 

ü Horizontal Scaling