Performance management is becoming more and more important in IT environments. Did you ever wonder why your Web transactions are not completing fast enough? What if I told you that you can identify how much time each middleware application uses when it processes the transaction? What if I also told you that you can identify which workload is contributing the most to the overall system CPU utilization? Furthermore, what if your system's processing power could be automatically adjusted to ensure that your customized performance goals are met?

Not only can IBM's Enterprise Workload Manager (EWLM) monitor the performance of work according to the performance goals that you define, but it can also automatically adjust the processing power among partitions to ensure that performance goals are met. EWLM has the ability to monitor workloads across system and subsystem boundaries, regardless of operating system, in both small and large environments. These workloads can run on any combination of operating systems, such as AIX, HP-UX, Linux, i5/OS, Solaris, Windows, and z/OS.

EWLM solves many problems when it comes to managing workloads in your domain and ensuring that the work completes within acceptable performance metrics. EWLM does the following:

• Monitors application-level transactions separately from operating system processes
• Adjusts the processing power from one partition to another to ensure that performance goals are met
• Reports hop-level data that shows the amount of time that the transactions incur at each hop
  Provides a topology view of your domain that shows the flow of work from one application or server to another
• Reports how much the application-level transactions versus operating system processes contribute to the overall system CPU usage

This article provides you with an overview of EWLM and explains how EWLM works.

Customizing EWLM to Your Performance Needs

To begin with, EWLM uses a domain policy. The domain policy is defined by you and contains specific performance goals that suit your performance needs. It uses classification rules that identify specific work that you want EWLM to monitor. These classification rules are defined in transaction classes, process classes, and partition classes, depending on what types of work you want EWLM to monitor. Then, EWLM assigns each class to a performance goal that you define. This allows EWLM to identify which work to monitor and which performance goal that set of work is to use.

The Web-based EWLM Control Center application makes it simple to manage a domain policy. See Figure 1.

Figure 1: The EWLM Control Center looks like this. (Click images to enlarge.)

Monitoring Workloads Within an EWLM Domain

For EWLM to monitor work properly, it classifies the work processed by the EWLM domain to a transaction class, process class, or partition class. Each class can be viewed as a separate workload, and each contains classification rules that define which work is to be assigned to that class.. The following is an example classification rule for an IBM Web-serving plug-in transaction class:

EWLM classifies work when it first enters a system or application in the EWLM domain. Then, EWLM monitors the performance of that work according to the performance goal defined for that class of work. The type of classification that occurs depends on the type of work that enters the domain. The following are the three types of classification that can occur.

Transaction Classification: Application-Level Transactions Only

Transaction classification is the process in which EWLM assigns application-level transactions to transaction classes. Transaction classification is for middleware applications that typically process transactions in parallel. EWLM can monitor transactions for any application that instruments the Application Response Measurement (ARM) 4.0 APIs. The ARM APIs allow EWLM to collect the necessary performance data for the transactions that the applications process. Applications that are ARM-instrumented include WebSphere Application Server, IBM Universal Database, and IBM Web-serving plug-ins. In addition, these APIs allow EWLM to track transactions as they flow (or "hop") from one application to another

For example, a transaction may begin in an HTTP Web server. Then, the transaction hops to the WebSphere Application Server and then hops to DB2 to complete processing. From start to finish, this transaction incurs three hops. EWLM monitors this transaction as it flows from one hop to another because of ARM 4.0 instrumentation. In addition, EWLM can report to you how much time the transaction incurs at each hop, thus allowing you to pinpoint which hop may be the cause of a performance problem. The following table illustrates this example:

Process Classification: Operating System Processes Only

In process classification, EWLM assigns operating system processes to process classes. Process classification is for operating system processes such as i5/OS jobs, daemons, service processes, and so on. EWLM can monitor operating system processes on AIX, HP-UX, i5/OS, Linux, Solaris, and Windows.

Partition Classification: All Work for a Partition

Partition classification is the process in which EWLM assigns all work that a partition processes to a partition class. The applications that run on the partition do not have to instrument ARM APIs for EWLM to monitor their transactions. But, on the flip side, EWLM does not collect hop-level detail for partition class work. A partition class allows you to monitor all work that a partition processes against a single performance goal that you define.

Customizing Performance Goals to Your Business Needs

EWLM not only provides you with the basic performance management data (such as the overall system CPU utilization), but also compares the actual performance of work to an expected performance goal.

When you define the transaction classes, process classes, and partition classes in a domain policy, you also assign each class to a performance goal.

The following are possible performance goals that you can use:

• Average response time
• Percentile response time
• Velocity
• Discretionary

Example Classes and Performance Goals

To give you a better understanding of the granularity that EWLM allows when defining performance goals in a domain policy, examine the following example transaction classes, process classes, and partition classes and the performance goals for each class.

Note: The following terms are used in the examples:

• Position—Indicates the order for EWLM to use when classifying work to a class. EWLM uses position 1 first. Transaction classes have a default transaction class (in the highest numbered position) to ensure that EWLM classifies all transactions. Process classes and partition classes do not have a default class. If EWLM does not find a class to classify the work to, EWLM does not classify it or monitor it.
• Application—Indicates the name of the application that EWLM is to monitor. Each application has its own set of transaction classes.
• Platform—Indicates the name of the platform whose operating system processes EWLM is to monitor. Each platform has its own set of process classes.
• Classification rules—Identify which work EWLM is to classify to the class. The classification rules use the following symbols: Logical operators AND/OR (to join rule statements), wild card ("(*)", represents any unlimited number of characters), and mask ("(?)", represents any one character that can be used anywhere in the rule value).

Transaction Classes

The example shown in the table below illustrates how you can identify three workloads, each with a different performance goal. EWLM uses these classes when transactions for a Web-serving plug-in enter the domain. You may have other sets of transaction classes for other applications, such as WebSphere Application Server or DB2.

The first workload is in position 1 and contains a specific set of transactions. The work that EWLM classifies to this transaction class must contain the URI string defined and (AND) originate on server1. The performance goal for this transaction class is a one-second response time. The goal is met if 95% of the transactions that EWLM classifies to this class meet the one-second response time goal.

The second workload is in position 2. This workload is more general because the classification rule does not dictate that the work run on a specific system. The performance goal for this transaction class is a two-second response time. The goal is met if 85% of the transactions meet the two-second response time goal.

The third workload is in the last position, position 3. This is the default transaction class and is the most general because the rule uses the wild card value. The rule is not editable. The wild card rule allows EWLM to classify any transaction that has not yet been classified to the default class. The performance goal for the transactions in the default transaction class is an average response time of three seconds.

Tip: Even though you cannot edit the rule for the default transaction class, you can edit the performance goal.

Process Classes

The example in the table below illustrates how you can identify i5/OS operating system processes for EWLM to monitor. If a process meets the conditions of the classification rule, EWLM monitors the process's performance against the performance goal for that set of processes.

Tip: If you want EWLM to monitor all processes for a specific operating system, create a process class classification rule that contains a wild card value (*).

The example in the table below illustrates how you can identify AIX operating system processes for EWLM to monitor. If a process meets the conditions of the classification rule, EWLM monitors the work against the medium-velocity performance goal.

Partition Classes

The example in the table below illustrates the most general way for EWLM to monitor work. Partition classes include all work that a partition processes. Then, EWLM monitors all of the work for the entire partition against a single performance goal.

Tip: If EWLM classifies work to a partition class, EWLM may also classify that work to a transaction or process class, depending on which type of work it is. This allows you to monitor the performance not only of the entire partition, but also of a specific set of transactions or processes.

Examining Performance Data

EWLM provides a robust set of monitors and reports that help you pinpoint the exact cause of a performance problem.

Hop Details Report

The hop details report allows you to view performance statistics for application-level transactions as transactions flow through a multi-tiered application environment. The hop details report is very useful because it provides you with performance data that is specific to each hop. Therefore, you can pinpoint the exact hop that may be the cause of a performance problem.

For example, in the report shown in Figure 2, you can view the hop details for the transactions classified to a transaction class. This report indicates that the actual performance, on average, for the entire class of work is two seconds. This is the average amount of time that elapses from the moment the transactions start to the moment they end. You can use this report to determine how much time elapses at each hop. Compare the time values for each hop to see if they are acceptable. You may determine that one hop is taking longer than expected to process transactions. You can use this report along with a managed server details report to examine the size of the system's CPU usage and workload to pinpoint performance bottlenecks.

Figure 2: Use the hop details report to pinpoint performance bottlenecks.

Managed Server Details Report

The managed server details report allows you to view which workloads are processed on each managed server in the domain. This allows you to determine how much each workload is contributing to the overall system CPU usage.

For example, in the report shown in Figure 3, you can compare the processor usage percentage for each service class. Note that each service class may contain work for more than one transaction, process, or partition class. You can use this data to determine whether your high-priority workloads are obtaining the resources needed to complete within your performance goals. In addition, if you have a service class for application-level work and a service class for operating system processes, you can determine which type of work is contributing the most to the overall system CPU usage.

Figure 3: Use the managed server details report to see the processor usage for each service class.

Topology Report

In addition to reporting performance data, EWLM also provides a topology report, as shown in Figure 4. The topology is a graphical representation of how work flows through the systems and applications in your domain. From this view, you can obtain a topology details report that provides you with performance data in table format for the entire domain. The topology details report is similar to the hop details report, but the topology details report includes the entire topology.

Figure 4: The application topology report shows how work flows through the systems and applications in your domain.

EWLM Provides Worry-Free Workload Management

Managing the performance of workloads can be very difficult. It's hard to pinpoint the exact cause of a performance problem, especially if the only performance data you have are the CPU utilization rates and the transaction statistics. The CPU usage may be at an acceptable threshold, and a high percentage of transactions may complete successfully, but are the transactions completing within the specific time interval that you want?

EWLM is the answer to performance management problems. It provides robust and advanced performance capabilities that help you pinpoint the exact cause of performance problems. EWLM is robust in that it provides hop-level performance data that may span multiple operating systems. EWLM is advanced in that it can detect where performance problems exist and automatically make resource adjustments to alleviate bottlenecks. These resource adjustments not only factor in the system CPU usage but also take into account whether the performance goals for the workloads that run on that system are met.

To take advantage of these performance management capabilities, you simply need to define an EWLM domain policy that is specific to your performance needs. Then, sit back, relax, and let EWLM manage the workloads in your IT environment.

For more information on EWLM and the functions described in this article, see the following Web sites:

EWLM topic collection in the IBM Systems Software Information Center

IBM Systems Software Information Center
 

Connie Cradick, a Staff Software Engineer at IBM, is the information development lead for Enterprise Workload Manager (EWLM) and is an IBM patent owner. She works with development and conducts usability tests to ensure that the user interfaces and documentation are user-friendly, clear, and concise. She has robust experience designing and documenting the IBM Virtualization Engine's EWLM. Prior to EWLM, she obtained extensive experience with i5/OS system values, i5/OS work management, and various job schedulers.

Connie joined IBM in 2000 and received her Bachelor of Science degree with summa cum laude honors from the University of Minnesota. You can contact Connie at This email address is being protected from spambots. You need JavaScript enabled to view it..

Also Read

TD/OMS and Gravity “Milestone 1” Enhancements Streamline Efficiency and Advance Application Development Potential for Re...

Now Let’s Consider Vendor Maintenance

Know Where Your Maintenance Stands