Drilling deeper into OpenEdge Management-supplied data
In addition to the considerations noted in Table 8–1, the system administrator reviews the data gathered weekly through the AppServer Application Profile report. When the company installed and started to use OpenEdge Management, they began using the predefined report template feature to run report instances on a weekly basis. This report's data provides the administrator with a high-level picture of the application's health. The Reporting Guide helps to set up and use the AppServer Profile report and all the other OpenEdge Management-generated reports.
Looking at the AppServer Profile report
The purpose of the AppServer Profile report is to provide details about procedures run by a broker. The data captured by this report can include these elements:
In this instance, the administrator has customized his AppServer Profile report. As shown in the graphical data displayed in Figure 8–1, this AppServer Profile report presents information about the average time it takes for two different procedures to run on the AppServer. Reviewing and routinely comparing reports from different time periods provides this administrator more insight into the AppServer's performance.
Finding performance-related clues in the AppServer Profile report
The administrator knows that reviewing performance details about two of the ABL procedures might provide performance clues. Performance issues related to these high-level rate procedures—zeta.p and zed.p—might impact the application's performance.
Figure 8–1 displays typical AppServer workload-related data that is consistent with an average weekday afternoon at the XYZ Corporation.
Figure 8–1: AppServer Profile Report for Average_Afternoon data Note: In the figures presented in this section, the colors in the graphs are intended only to distinguish one procedure from the other.
![]()
The AppServer Profile report that appears in Figure 8–1 is set up to:
By selecting the Average Procedure Duration High rule on the AppServer's monitoring plan and identifying a polling interval threshold for it, the administrator can monitor the AppServer's performance and behavior based on values that are significant to his performance expectations. For details about this rule, see the "Average Procedure Duration High rule" section. For details about monitoring plans, see Chapter 6, "Monitoring Plans and Rules for OpenEdge Server Resources."- Capture the average time that it takes two individual ABL procedures—zeta.p and zed.p—to run during the system's peak operational time.
- Display this data in a graphical mode in a browser.
These two procedures, zeta.p and zed.p, are among the procedures that the AppServer broker, asbroker1, is currently running. This is the kind of normal, predictable AppServer procedure processing that a system administrator likes to see; resources are being used and consumed, but not overly taxed so that the users' and the company's business needs are being well met.
The administrator compares the report data results from previous weeks to the data results that appear in Figure 8–3. The fact that the procedure zed.p is hovering at the defined threshold use of 40,000 indicates that there is likely an otherwise hidden performance issue to investigate.
![]()
Figure 8–2: AppServer Profile Report for Bad_Afternoon data
The same type of average request duration data that displays in Figure 8–2 tells a very different story about another workday afternoon at XYZ Corporation. By comparing the generated data in Figure 8–1 with the generated data for the same procedures and associated brokers in Figure 8–2, the administrator can see that the slow growth in the average time it takes to complete a process requested by either the zeta.p or zed.p does cause problems if left on this current growth rate. As Figure 8–2 shows, these procedures are either exceeding, or trending toward the possibility of exceeding, the threshold of 40,000. Given the data as reported in the Bad_Afternoon report, the administrator could begin to make some notes about the application's response to pass along to the company's programmers so that they can consider changes to rebalance the work load.
The administrator's routine review and comparison of the data presented in Figure 8–1 and Figure 8–2 have helped him to thwart a potential application crisis. This problem detection points to where the administrator's code review with developers or system engineers should begin.
Using report data to minimize an impending application performance crisis
Figure 8–3 shows the type of data the system administrator could have faced without diligence in routine review and investigation of OpenEdge Management report data.
Figure 8–3: AppServer Profile Report for Crisis_Report data
![]()
Assuming the same 40,000 threshold for all of the procedures listed in Figure 8–3, it is very apparent that processing on this work day afternoon has reached crisis proportions. Not only are the procedures zed.p and zeta.p exceeding the threshold, the lockme.p procedure is causing more problems at approximately 1:30 PM and again at 3:30 PM.
Copyright © 2006 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |