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.
The following figure shows typical AppServer workload-related data that is consistent with an average weekday afternoon at the XYZ Corporation.
Figure 51. 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 the above figure is set up to do the following:
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.
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 monitoring plans, see Monitoring Plans and Rules for Servers, DataServers, Messengers,and Adapters .
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 53. 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 52. AppServer Profile Report for Bad_Afternoon data
The same type of average request duration data that appears in the above figure tells a very different story about another workday afternoon at XYZ Corporation. By comparing the generated data in Figure 52 with the generated data for the same procedures and associated brokers in the above figure, 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 51 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 51 and Figure 52 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.
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.
