Data power Performance Tuning

Data power Performance Tuning:
Listed down tips can be incorporated within data power services for maximizing performance.
1) By adjusting caching mechanism according to our needs :
Caching is the most important option for performance tuning, think of the time used for network
communication, retrieval of WSDL documents or compiling XSLT files.
WebSphere DataPower provides many options for caching, you can cache XSLT files, documents
(specifically remote documents), WSRR WSDL retrieval, LDAP/TAM responses and others, below
describes the steps to cache the objects mentioned earlier.
XSLTs and Documents
XSLs are cached by default. You can set the number of XSLs to be cached by specifying this option in
the XML Manager:
Open Objects > XML Processing > XML Manager > Your XML Manager (or default)
Set XSL cache size to the desired number.
To cache documents, open the Document Cache tab in the XML Manager and set the Document
Cache Count to an appropriate number and Document Cache Size to an appropriate positive number.
To cache remote documents do the following:
1. Open the Document Cache Policy tab
2. Click Add
3. Enter the URL Match expression which is any URL either internal or external to the device (ex: WSRR
REST Calls)
4. Complete the rest of the form
5. Apply and Save
Figure 7. Document Cache Policy

WSRR WSDL Retrieval
If you are using WSRR WSDL subscription, the WSDL Retrieval is cached by default, make sure you
have selected the appropriate refresh interval.
1. Open Control Panel > Web Service Proxy > Your Proxy
2. Open WSDL tab
3. Expand you WSDL subscription
4. Enter an appropriate value for Refresh Interval (note: the default value is ok if you do not have any other
preferences)
Figure 8. WSDL Refresh Interval
AAA Cache
In the AAA object, the authentication and authorization Cache is set to 3 seconds by default, unless you
have a requirement or a logical reason for leaving it low (increasing cache time can lead to weaker
security) it will be beneficial - from performance perspective - to increase this value.
Open Objects > XML Processing > AAA Policy > Your Policy
In the Authenticate tab increase the value of Cache Lifetime, in Authorize tab increase the same value.
Figure 9. TAM Authorization Cache Lifetime

2) By making persistence connections off :
HTTP Persistent connections means reusing opened connection for sending multiple messages instead
of opening/closing a connection for each message, this option decreases CPU cycles, network traffic and
latency. For more information check HTTP Persistent Connections in the Resources section.
WebSphere DataPower supports Persistent connections for inbound/outbound calls as part of HTTP/1.1
specs, it is enabled by default in HTTP related services such as HTTP front side handler, Web Service
Proxy and XML Firewall, below is an example of how to control this option in the Web Service Proxy.
1. From the Control Panel Open the Web Service Proxy > Your Proxy
2. Open the Advanced Proxy Tab
3. You can set Persistent Connections "On" or "Off" and specify persistence timeout
Figure 10. Persistent connection settings

3) Working with processing rules (make i/p , o/p pipe)
PIPE and NULL Contexts
Whenever applicable use PIPE as Input and Output between two contiguous action nodes, this will
prevent extra context processing and will keep memory usage down.
Use NULL as Input or Output of any action that doesn't need to produce or use predecessor actions'
results (ex: using a Transform Action to set context variables only), this is beneficial because you will
save the time of creating and parsing contexts and the action becomes more readable and self
describing, plus the solution will consume less memory.
Asynchronous Rules
Limit the usage of asynchronous rules because as you can imagine parallel processing will increase CPU
Utilization (Context Switching) and will use more memory, also note that this applies to asynchronous
actions too.
Reusable Rules
Reusable rules are often called many times from parent rules, this may introduce redundancy in action
node execution, when using reusable rules, make sure you include only actions that needs to be called
many times, other actions (such as Transform Action to set a variable) may be moved to the parent flow
to avoid redundancy.
XSLT Code
Code for performance from the beginning, below are some XSLT Performance tips.
1. Avoid using "//"; specify the node you are targeting using its absolute tree path
2. Do not retrieve the same information twice, if you are using dp:variable function or selecting a value from
a document <xsl:value-of select="document(/path)"/> more than one time in the same file, it will be
better to save it in a variable once and use the variable for later references.
3. Try to import interdependent interrelated xslt file within one as most as possible thus reducing the number
of loading individual xslts .
4) Working with MQ objects :
When connecting to MQ, use "dpmq://" (which uses a configurable MQ Queue Manager Object) instead
of direct MQ connection "mq://", using direct MQ connection will create a queue manager object at

runtime and will open a new connection with MQ for each call, instead if you used theMQ Queue
Manager Object you will have connection pooling and many other good options.
You can create the MQ Manager Object by doing the following:
1. Open Objects > Network Settings > MQ Queue Manager
2. Click Add, complete the form and Apply
3. You can then use the name of this object in "dpmq://" urls
Figure 11. MQ Queue Manager

5) Conveniently using Synchronous and Asynchronous actions
a) DataPower actions may be executed as "synchronous" in which subsequent actions wait
for completion, or "asynchronous" in which actions run in parallel. By default, actions are
synchronous, each waiting for its preceding sibling to complete. Normally, this is the
desired behavior. Certain actions, such as authentication and authorization (AAA) or
service level monitoring (SLM) should only be run synchronously as subsequent actions
are executed based on their successful execution. However, for some policy rules, it is
possible to run actions in parallel. An example is posting log data to an external service. If
the log server slows down, you may not want the client's transaction to delay if the log
event is non-critical.
b) However, asynchronous actions are not cost-free. DataPower is primarily optimized for
minimizing delay. As a transaction executes each action in a rule, it does not free the
memory used until after the transaction completes. Rather, it puts that memory in a
"transactional or hold" cache for use by subsequent actions. The memory will only be free
after the entire transaction has completed. It is not available for use by another
transaction until such time.
c) Asynchronous actions can overuse resources in conditions where integrated services are
slow to respond. Consider an action that sends a SOAP message to an external server.
The result of this action is not part of transaction flow and you do not want to delay the
response to the client waiting for confirmation from the server. The action can be marked
asynchronous. Assume that normally the external server responds with a HTTP response
after just 10 milliseconds (ms).
d) Now assume that you have a modest 100 transaction per second (TPS) flow to the
device and that the external log server has a slowdown and does not respond for 10
seconds to each SOAP message. Assume each transaction uses 1MB of memory,
parsing and processing the request transaction. Suddenly, your log actions are holding
1GB of memory as they wait for the HTTP responses from the logging server! This can
quickly cause the device to start delaying valuable traffic to prevent over use of
resources. If this logging is not business critical, you might want the logging actions to
abort before the main data traffic is affected. We'll describe how that is implemented
using a controlling or "façade" service, described in implementing a service level
management.

6) Using separate delegate service :
Now that we've described some of the basic components of transaction management, let's discuss some
simple ways to better regulate transaction flows. We've described monitors and SLM policies and how
you can easily use them to monitor transactions following through to backend services, and how you can
use these to control latencies in backend services. You can also use monitors and SLM policies when
interacting with "off box" services. We mentioned in our introduction how DataPower can interact with
many different end points and we've described a logging service as a good example. What happens when
that logging service become slow to respond? Transactions begin to queue up in DataPower and
consume resources. So, let's use these techniques to control that.
Rather than accessing the logging service directly through a results action, we'll create a "façade service"
and, within it, we will apply monitoring capabilities. This allows for the ability to monitor, shape, or reject
requests that are becoming too slow to respond. The façade service is necessary to encapsulate the
monitors as the results action by itself does not provide this capability. If you are using firmware version
5.0 or greater, you can also use a "called rule" in place of the façade service. The called rule contains the
monitors in this case. Figure 14 shows an example of our architecture.
Figure 14. Facade service as an “off box” gateway
Creating the façade service
Create the façade service on the same device to minimize network delays. It can, however, be in another
domain on the device. The SLM resource class should be concurrent connections. This is an important
point. Other algorithms have a potential vulnerability to a slow backend. But, concurrent connections do
not because it is an instantaneous counter.

The façade service's front side handler (FSH) is a simple HTTP connection. In this case, do not use
persistent connections. There are several reasons for this:
 First, over the loopback interface, there is no resource or performance penalty for not using persistence.
 Second, when using persistence the appliance caches some memory after each transaction, which can
increase the overhead of the service. Therefore, as there is no benefit, do not use persistence.
Figure 15 shows the simple façade service (or possible called rule). Again, all we are doing is
encapsulating an SLM policy within the path to the logging service.
Figure 15. Façade service rule with an SLM policy
The SLM policy is demonstrated in Figure 16, which shows the policy with one rule and the details of the
resource class (using concurrent connections), and the throttle action, which rejects messages. The
policy rule is using a fixed interval of one second with a "count all" threshold of 20. That is, allowing
concurrent transactions and rejecting those in excess of 20.
Figure 16. SLM policy to reject concurrent transactions greater than 20

Figure 17 illustrates the configuration change to the main processing policy. In the original rule,
transactions went directly to the logging service; in the second, they are sent to the façade service on the
loopback (127.0.0.1) interface.
Figure 17. Policy rule before and after using the façade service (see enlarged Figure 17)
It's a simple as that. We have now altered our configuration to monitor transactions to the logging service.
When they are excessively slow, we reject the entire transaction.
In summary, some of the best practices for using the façade service are:
 The backend can be any protocol; it is HTTP for this example.
 All actions in the rules must be synchronous.
 The response message type should be pass-through (unprocessed).
 The request type should probably be non-XML (preprocessed) for minimum overhead.
 All other settings are set as defaults.
 If necessary, you may want to explore streaming and flow control. This is useful if you are using an
asynchronous action to send large amounts of data.
 The request rule should have a single action, which is SLM.
 The input and output of the action should be NULL.
 The SLM policy should have a single statement that uses the concurrent connections resource.
 The statement should reject the extra transactions.
7) Delicately handle contexts variable within the code:
Care must be taken when defining processing policy rules to avoid unnecessary memory usage. Most
actions create output "context" and it is important to realize that each new context represents an
additional allocation in memory. Figure 6 shows an example of two transform actions that create context
(ContextA, ContextB), which is then sent to the output stream through a results action.
Figure 6. Processing actions that create new context

In many occasions, you can use the special "PIPE" context to avoid this intermediate context creation.
The PIPE context does not require separate memory for each processing step and has other
performance advantages as well. While some actions require an intermediate context, and in some cases
you'll need to have noncontiguous processing patterns, you should ensure that each processing policy is
reviewed for optimum context usage.
Figure 7. Processing actions using PIPE to past the context
Another important tool regarding context is the use of the special "NULL" context. This "bit bucket" is
useful when an action does not produce meaningful output. Perhaps all you need to do is log some data,
or set a dynamic route. If you are not modifying the message, subsequent actions can access the original
input data and you do not need to pass it along with XSLT "Copy" statements and the unnecessary
production of context.
8) Adjusting time outs value and latency :
Latency and timeouts are important factors in memory consumption. Consider a typical scenario in which
requests are being processed through DataPower and onto a backend service. Transaction rates are
high, throughput is as expected. Now consider that the backend service becomes slower to respond, but
it is responding and not timing out. Requests come into DataPower at the previous rates, unaware of the
slowdown occurring on downstream services. But, the transactions are not completing until the response
is received from the backend and potentially processed within a response rule. DataPower must maintain
the request data and variables produced during response rule processing.
In addition, latencies may not be associated with the service's "backend", but by other endpoints
accessed during request or response rule processing. There are a variety of interactions that may take

place. Logging, authentication, orchestrations, or other integration services may be called. If they are slow
to respond, the transactions are slow to complete. If transactions are accepted at a continuous rate, they
begin to queue up in an active and incomplete status. These transactions hold onto resources until they
complete.
Backend timeout values are set at the service. The default values are typically 180 seconds and controls
initial connections and the maintenance of connections between transactions. User agent settings (which
are identified from the service's XML Manager Object) are used to specify the timeout values of "off-box"
or inter-rule requests. The default value is 300 seconds. This is probably too much and more restrictive
values should be used, allowing connections to fail when connections cannot be made in a realistic time.
Timeouts vary between endpoint types (HTTPS, ODBC, and so on) and may be dynamically altered using
extension functions. Consult the product documentation for your specific service configuration.
Timeouts may be identified by log messages and analyzed through the use of log targets, which consume
these events. Latencies are potentially more insidious. You may not be aware of increases in latencies
(unless you are monitoring these values). However, you may use monitoring techniques, such as SNMP
monitors to query service rates and duration monitors. Some customers will utilize latency calculators
through XSLT and potentially create log message, which again can be consumed by log targets for
dynamic configuration or analysis.

9) Shaping and throttling the transactions :
DataPower constantly monitors system resources, including memory and CPU. To avoid an
excessive use of resources, throttle settings allow for a temporary hold on incoming transactions until
the constraint is relieved. Using these throttle settings allow for inflight transaction to complete before
additional transactions are accepted. In a typical high availability environment, transactions are
processed by other appliances in the HA peer group, relieving load on the saturated appliance. Figure
8 shows the default values for throttling. In this example, when memory is at 20% of available
memory, the firmware waits "timeout" seconds and then reevaluates the memory. If the memory
constraint has not cleared, the firmware restarts. If at any time memory falls below the "Terminate At"
value, an immediate restart occurs.
10) Figure 8. DataPower memory throttle settings

You can use the backlog queue to hold incoming transactions while waiting for the resource
freeing. The "Backlog Size" number or transactions (currently limited to 500) can be queued for a
maximum of "Backlog Timeout" seconds. If the backlog size is at its default of "0", transactions
are immediately rejected during throttling. As the throttle process evaluates memory and other
resources, it can be configured to produce detailed log messages. Setting the "Status Log" to
"on" from its default of "off" produces messages like those shown in Listing 1. Memory, Port, Free
space, and File System snapshots are captured. As with all log messages, you can send these

events to a process for further processing. That process can, for example, be another DataPower
service that executes XML management commands to modify the configuration settings.
11) Listing 1. Example of throttle status log entries
12) 1,20130407T125910Z,default,usage,info,throttle,Throttler,0,,0x0,,,
13) "Memory(3923046/4194304kB 93.5% free) Pool(250) Ports(872/874)
14) Temporary-FS(158771/202433MB 78.4% free) File(OK)"
16) "XML-Names Prefix(2/65535 100.0% free) URI(83/65535 99.9% free)
17) Local(1374/65535 97.9% free)"
19) "Memory(3920133/4194304kB 93.5% free) Pool(417) Ports(872/874)
20) Temporary-FS(158771/202433MB 78.4% free) File(OK)"
You now understand some of the resources available to you. You see how the memory data is
used to dive into domains, services, and individual actions to see where memory resources are
being consumed. Next, we're going to discuss some tools that are important in performing
dynamic analysis of transaction flows and that can be used to affect transaction rates. Later, we'll
discuss critical issues of transaction flow regarding interaction with services off the appliance,
such as the logging service and backend resources. You'll see how they can greatly affect
transaction flow and how you can use the service level monitoring tools to mitigate these issues.
10) Suitably using message counts and monitors:
Count monitors and duration monitors provide a simple method of transaction control. Both monitors work
by selective execution of a "filter action". The filter action can shape or reject transactions, or simply
produce a logging message. Of course, logging messages can trigger logging events, including
monitoring actions and alerts.
Shaping involves the queuing of transactions for subsequent processing. The option to shape messages
should be done carefully. Shaping is used to minimize the number of transactions that must be rejected in
the time of a brief and temporary network spike. For example, if a backend server is experiencing a
period of high utilization and begins to show increased latency, DataPower can limit the traffic to this
server and the server may recover. If the period is relatively brief, it may be preferable for DataPower to
queue a few transactions in memory rather than rejecting them. The transactions can be released when
the backend latency has decreased. This can have the benefit of reducing the number of errors seen by
the clients.

The drawback to shaping is increased memory utilized to hold (queue) the transactions. If the spike is too
long, resources may be constrained before transactions can be released. Once accepted into the shaping
queue, you cannot cancel a transaction. The queue size is fixed and you cannot configure it. These are
important considerations to take into account when choosing to shape traffic.
One important factor in the duration monitor filter calculation is that duration monitors measure the
average time for transactions to complete. It is important to note that the algorithm only considers the
average time of the last several transactions. It is not an absolute limit of a single transaction. A common
use case is to configure a monitor that generates a logging event if the average total latency of the
service is climbing above some threshold.
Figure 9 shows the definition of the filter action. Within this configuration, the filter action is defined, which
is "Shape" in this case.
Figure 9. Monitor filter action rejecting messages
The messages to which filter rules are applied can be selective. You can use a variety of conditions to
determine the characterization of messages used for filter calculations. For example, the URL of the input
message, HTTP headers, and HTTP methods might be part of the conditional filtering. Figure 10 shows
an example of selecting only those messages whose HTTP method is POST.
Figure 10. Message type definition selecting POST HTTP method

Combining the message type and filter action produces the count or duration monitoring object. In the
example in Figure 11, POST type messages are counted. When they exceed 100 TPS (1000 Millisecond
interval), the messages are "shaped" or placed into the temporary queue and executed at a controlled
rate. The threshold calculation includes a "Burst Limit" value. This value allows for an uneven transaction
rate and accommodates a calculation in which "unused" counts in previous intervals are allowed in
successive intervals. The general best practice is to use an interval of at least 1000 milliseconds and a
burst rate of 2 times the rate limit.
Figure 11. Count monitor with message type and filter action (see enlarged Figure 11)

11) Working with service level monitors:
Service level monitoring (SLM) extends count and duration monitors by providing a more selective basis
for transaction analysis and the ability to combine SLM rules or statements to develop complex
monitoring processes.
SLMs are configurable as a processing action within the processing policies of Multi-Protocol Gateways
and Web Service proxies. An SLM action specifies an SLM policy object, and each of these objects is
composed of an ordered sequence of one or more SLM statements. Each SLM statement defines a
separate set of acceptance and enforcement criteria as well as the action to be taken. SLM policies
provide the option to execute all statements, to execute statements until an action is taken, or to execute
statements until the policy rejects a message. Figure 12 shows a configured SLM policy containing a
single SLM statement.
Figure 12. SLM policy with a single policy statement (see enlarged Figure 12)
Each SLM statement provides a number of options to be configured:
 Credential and resource classes: These specify criteria used to select to which incoming messages the
statement will be applied. This may include user identity details from an authentication action,
transactional meta data, such as URL or transport headers, or custom information provided through a
user-written XSLT.
 Schedule: This specifies the time frame when the statements will be applied. This provides for the ability
to preconfigure events such as downstream application maintenance or "Black Friday" shopping events.
 SLM action: This specifies the action to take if an incoming message exceeds the statement's threshold,
which is typically either notify, shape, or reject. These are similar to the count and duration monitor
actions.
 Threshold interval length: This specifies the length of the measurement interval in seconds.
 Threshold interval type: This specifies how intervals are measured. Intervals can be fixed, moving, or
concurrency based.
 Threshold algorithm: This specifies how incoming messages are counted within a threshold interval.
Typically, a simple "great-than" algorithm is used to cap transaction rates. However, a more complex

algorithm such as "token-bucket", which is similar to the Monitor "Burst Rate" calculation, is also
available.
 Threshold type: This specifies how incoming messages are applied to a threshold interval, either by
counting or by tracking latencies.
 Threshold level: This specifies the trigger point where the action is executed.
Figure 13. Example of an SLM statement
Figure 13 shows the SLM statement form. You can combine multiple SLM statements to provide for
sophisticated service level agreements and throttling procedures. By configuring a set of SLM statements,
each of which is tailored to handle a particular situation that can lead to memory or resource exhaustion,

the appliance as a whole can be better protected from the negative impacts of anomalous situations
within clients, side services, and back-end servers. The SLM design strategy is to limit the flow of
incoming messages when there is the potential for slow transaction processing times leading to a build-up
of transactions being processed, since each in-process message consumes resources of the appliance.
The following sections describe how you can configure each of the SLM options to handle these types of
situations.
12) Working with the data streaming in the XSLT:
An alternative to document parsing is the "streaming" of documents through a service policy. In this
scenario, the document passes through a policy rule, section by section, and while the entire document is
not accessible, this is often all that is required. In streaming mode, memory requirements are greatly
reduced. Streaming requires strict adherence to processing limitations, including XSLT instructions that
may be invoked. For example, an XSLT XPath instruction cannot address a section of the document
outside of the current "node" of the document as it will not be available.
While streaming processes extremely large documents, you must follow the requirements. You'll need to
create streaming rules and compile options policies and check to ensure your XSLT conforms to the
streaming limitations
Please Refer: http://www-
01.ibm.com/support/knowledgecenter/SS9H2Y_5.0.0/com.ibm.dp.xi.doc/optimizingthroughstreaming.htm
****************************************************************************************************
References:
http://www.ibm.com/developerworks/websphere/library/techarticles/1307_rasmussen/1307_rasmussen.ht
ml
http://www.ibm.com/developerworks/library/ws-dpperformance/
http://www.programmershare.com/2571995/
https://blog.codecentric.de/en/2008/07/xsl-performance-tuning-2/
http://www.ibm.com/developerworks/websphere/library/techarticles/1410_sahoo/1410_sahoo.html
https://github.com/pglezen/dpShowLatency

Data power Performance Tuning

Recommended

More Related Content

What's hot (20)

Viewers also liked (15)

Similar to Data power Performance Tuning (20)

Data power Performance Tuning