> #### Drilling deeper into Fathom-supplied data

> In addition to the considerations noted in Table 8–1, the system administrator reviews the data he gathers weekly through the AppServer Application Profile report. When his company installed and started to use Fathom, he began using the predefined report template feature to run report instances on a weekly basis; this report's data provides him with a high-level picture of his application's health. The Reporting Guide helped him to set up and use the AppServer Profile report and all the other Fathom-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:

> - How many times a specific procedure ran.
> - The average and maximum durations of each request.
> - The number of successful requests.
> - The number of errors.
> - The number of times each request quit and stopped.

> 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 his AppServer. Reviewing and routinely comparing reports from different time periods provides this administrator more insight into his AppServer's performance.

> ##### Finding performance-related clues in the AppServer Profile report

> This administrator knows that reviewing performance details about two of his Progress 4GL procedures might provide him performance clues. Performance issues related to these high-level rate procedures—zeta.p and zed.p—might impact his 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 — Average_Afternoon data

> Note: In the figures presented in this section, the colors in the graphs are only intended to distinguish one procedure from the other.

> The AppServer Profile report that appears in Figure 8–1 is set up to:

> - Capture the average time that it takes two individual Progress 4GL procedures—zeta.p and zed.p—to run during the system's peak operational time.
> 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."

> - Display this data in a graphical mode in a browser.
> Note: In the figures presented in this section, the colors in the graphs are only intended to distinguish one procedure from the other.

> 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 his users' and his company's business needs are being well met.

> This administrator compares his report data results from previous weeks to the data results that appear in Figure 8–2; 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 for him to investigate.

> Figure 8–2: AppServer Profile Report — 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, this 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 re-balance the work load.

> This 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 had he not been as diligent in his routine review and investigation of Fathom report data.

> Figure 8–3: AppServer Profile Report — Crisis_Report data

> Assuming the same 40,000 threshold for all of the procedures listed in Figure 8–3, it is very apparent that 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 definitely causing even more mayhem at approximately 1:30 PM and again at 3:30 PM.

Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095