Optimizing Application Performance

.pearl-hilighted-word {background-color: #ffffff !important; color: #000000 !important;}

EntireX

Issue 4, 2013

Download pdf

Optimizing application performance is about collecting key response-time data, analyzing the data in ways that represent application behavior, and clearly reporting the significance of individual or overall performance indicators to application stake holders. EntireX’s new built-in features, along with Optimize for Infrastructure, provide a flexible solution for monitoring, measuring and optimizing complex cross-system applications. 

This article covers the following information:

  • What application performance monitoring is and who should use it
  • How response time monitoring is used to elicit gains in application optimization
  • Specific use-case scenario and explicit examples
  • Hints and tips on deployment along with run-time observations

This information supplements an earlier monitoring article by Wil Heynan, Revolutionizing Application Monitoring, by focusing on EntireX 9 features and monitoring examples using Optimize for Infrastructure 9.

What is application monitoring?

The intent of application performance monitoring is to empower users to achieve a higher level of application performance by tapping into detailed and aggregated key performance indicators—deriving detail knowledge of application run-time behavior. As a result, users gain visibility into bottlenecks and potential problems while being able to continuously optimize their application’s overall performance
EntireX transparently supports application monitoring for any RPC application or webMethods Integration Server applications using the EntireX Adapter with CICS® or IMS™ connectivity features. EntireX RPC automatically collects detailed response times along the RPC messaging path to publish to Optimize for Infrastructure which persists, analyzes and reports on the most important aspects of application performance. In addition to application monitoring, Optimize for Infrastructure also supports infrastructure (operational) monitoring of many Software AG transaction, integration and business process products.

Using monitoring to optimize applications

Figure 1 highlights how a typical RPC client/server application is monitored to gain knowledge of end-to-end performance. Note that there are finite-element metrics, Key Performance Indicators (KPIs), for each process response time and for each transport component along the execution path that collectively make up the total response time. The right column of the figure describes how each component in the end-to-end flow is configured using default KPIs.

Figure 1: Application monitoring example using a Natural RPC Server

1. The client application issues a remote procedure call and the client RPC layer gets control. At the end of a transaction, the client RPC layer gives the control back to the client application. The time spent in the client RPC layer is monitored by the Time - Client Layer KPI.

2. The client RPC layer calls the EntireX Broker. The transport time between the client RPC layer and the EntireX Broker plus the transport time spent on the way back is monitored by the Time - Client Transport KPI.

3. The time spent in the EntireX Broker is monitored by the Time - Broker KPI. The KPI value does not include the amount of time that the EntireX Broker spends waiting for an available server.

4. The amount of time that the EntireX Broker spends waiting for an available server is monitored by the Time - Broker Wait For Server KPI.

5. When the EntireX Broker calls the server program, the server RPC layer receives the call first. The transport time between the EntireX Broker and the server RPC layer plus the transport time spent on the way back is monitored by the Time - Server Transport KPI.

6. The time spent in the server RPC layer is monitored by the Time - Server Layer KPI.

7. The server RPC layer forwards control to the Natural server program. The time spent in the Natural server program is monitored by the Time - Server Program KPI. The KPI value does not include the time spent for database calls.

8. The Natural server program calls a database. The transport time between the Natural server program and the database plus the transport time spent on the way back is monitored by the Time - DB Transport KPI. This KPI is only available for Natural RPC servers issuing database calls against an Adabas server.

9. The time spent for database calls is monitored by the Time - DB Calls KPI. For non-Adabas databases, the KPI value includes also the transport time required to reach the database server.

For EntireX RPC, each service call that is configured for monitoring (according to Broker Service attributes) is monitored starting at the client RPC layer. Each RPC component along the execution path concatenates its response-time data within the service call payload. Each start and end point of the RPC pathway sends the associated event data to the application monitoring data collector where it is disassembled, calculated and persisted in Optimize. Resolution of performance metrics are in microseconds (equal to one millionth of a second).

Once Application Monitoring (AppMon) events are collected, they can be viewed and reported on in numerous ways. Figure 2 shows a MashApps bar chart in which each KPI is reflected in the horizontal length of the bar. The time KPIs are colored and labeled as the same nine numbers in the example. Each KPI is expressed as both the actual value and as a relative length.

Figure 2: MashApps bar chart displays the actual and relative values of KPIs

MashApps are Web-based MashZone apps that offer a variety of dashboard capabilities with out-of-the-box graphic display tools and pre-built connectivity (JDBC®-based) scripts to read Optimize application monitoring data. Use of MashApps is licensed through the MashZone tool under Optimize for Infrastructure. Optimize for Infrastructure requires a third-party database license (e.g., MS SQL®, Oracle®, DB2®).

 

Use case with EntireX Broker

Example 1:
Calling a CICS COBOL Server application through a z/OS® EntireX Broker from the EntireX Adapter using the webMethods Integration Server

First, here is a list of webMethods components that are assumed to be installed for this use case.  The application infrastructure for using an IS Java® service client that calls a CICS COBOL server program requires:

  • EntireX Broker on z/OS
  • EntireX CICS RPC Server
  • EntireX Adapter (Package on Integration Server)
  • Integration Server (IS)
  • Designer w/ EntireX and Service Development plug-ins

The monitoring infrastructure for collecting application KPI data, storing KPI and reporting response time information, requires:

  • Optimize for Infrastructure (analytics + database)
  • Universal Messaging (to support Java Message Service standard)
  • My webMethods Server (Optimize management)
  • MashZone (MashApps web-based dashboard)
  • Command Central (optional server manager)

The beauty of application monitoring using an existing RPC-based EntireX platform is that response-time agents are transparently built into the platform. This means that all you need to do is turn on the application monitoring parameters on the EntireX Broker and you can start collecting and comparing end-to-end performance metrics across all of your different systems supported by RPC.

There is a new Broker parameter called APPLICATION-MONITORING that initializes the AppMon feature at start-up, allows you to define a specific SERVICE to monitor, and designate where to send the response time data. The application monitoring collector is a listening service that must be running on a distributed platform and reachable by the EntireX Broker through TCP/IP.

Here is an example Broker attribute configuration for defining the AppMon defaults and for defining an RPC service to monitor across all RPC components:

************** APPLICATION MONITORING parameters***********************

DEFAULTS = APPLICATION-MONITORING                                     

  COLLECTOR-BROKER-ID = daetst02:57900                                

* Service for Application Monitoring                                   *

*----------------------------------------------------------------------*

DEFAULTS = SERVICE                                                     

  CLASS=RPC,SERVER=SRV1,SERVICE=COBOL,APPLICATION-MONITORING=YES,      

    APPLICATION-MONITORING-NAME=COBOL_Application                      

*----------------------------------------------------------------------*

Although you can easily turn on application monitoring for all services, a best practice is to start with an individual class/server/service name for testing purposes as each service name will automatically generate a monitored object in Optimize.

The APPLICATION-MONITORING-NAME is an optional tag that will become present in the Optimize application monitoring object visible through My webMethods Server (MWS) and MashApps (application monitoring RPC) as shown in Figure 3.

Figure 3: Tracking response-times with MashApps using friendly application name

This example shows how the friendly application monitoring name (COBOL-Application) is used in the MashApp in the Select Application pull-down. Note that for this application test scenario, the majority of time is spent in the client transport (yellow) since each call is transported from a PC in Seattle to a server in Darmstadt and back again with a network latency (ping time) of approximately 260 milliseconds.

It may be important to restart the EntireX Adapter connection service (if already running) after you have started a newly configured application monitoring service on the Broker.

For troubleshooting purposes, AppMon tracing can be set in the Broker attributes file. Any application or RPC run-time errors however, will be automatically collected and displayable from the same RPC Application Monitoring MashApp page by clicking on Error Transactions as shown in Figure 4.

Figure 4: Tracking transaction errors using Service name

In this MashApp example, we show all of the transaction errors from the last seven days using the Service name (RPC/SRV1/COBOL) instead of the friendly name.

Use Case with ECI Connection

Example 2:
Calling a CICS COBOL Server application through an ECI Connection from the EntireX Adapter using the webMethods Integration Server

For this scenario, all you will need to do is enable Application Monitoring through the EntireX Adapter’s Web admin tool as shown in Figure 5.

Figure 5: Application monitoring with EntireX Adapter’s Web admin tool

Enabling Application Monitoring will cause application monitoring events to be recorded in the Adapter log indicating it is connected to the proper data collector.

This Adapter feature will automatically monitor all CICS ECI, IMS Connect or Direct RPC connections and send the response times to the application monitoring collector. Once you send traffic over any of these connection types, you will see data in the MashApp Application Monitoring for CICS dashboard by selecting the proper host:port from the application in data collector pull down.

Summary

For existing EntireX RPC users who need to closely monitor and manage response time and errors at a detail level, Optimize for Infrastructure offers a scalable solution that can persist and analyze KPIs. The solution includes MashApps for flexible and friendly dashboard reporting through a browser. The EntireX application monitoring feature is totally transparent and supported across all EntireX RPC 9 or later components running over TCP/IP on z/OS, UNIX® or Windows®.

More detailed product information and requirements can be found here