|
|
   |
 |
           |
 |
  |
 |
|
              |
|
Managing COM+/.NET Components with AppMetrics® for Transactions. Xtremesoft's AppMetrics for Transactions is designed to monitor the health of applications in test and in production on Windows 2000 Advanced Server, Windows Server 2003, and Windows Server 2008. The product enables developers, system administrators, and capacity planners to ensure a higher level of service over more servers, resolve 'finger-pointing' issues more quickly, and anticipate system capacity over time. Our focus is on business transactions implemented with registered .NET Serviced Components and COM+ Components (COM+ Components), regardless if they have been marked transactional or not. This includes metrics on packages, applications, components, and their methods. AppMetrics for Transactions does not require any changes to your source code or configuration. The product even works well with third-party components. You can install in your production environment and start reaping the benefits quickly and easily. AppMetrics for Operations Managers AppMetrics for Capacity Planners Overview AppMetrics for Transactions offers three main feature areas
After walking through each of the product's feature areas, this document provides a link where you can retrieve more information or sign up for an evaluation copy. Business applications implemented using COM+ components are comprised of many complex parts and usually the system administrator who deploys them and maintains their servers had little involvement with their development. To complicate matters further, bottlenecks can manifest themselves even in well-written components when hardware limitations are reached. When problems occur (and they will) system administrators want to be the first to know. The faster they can identify where, the faster they can resolve such problems. Setting up an early warning system ahead of time using AppMetrics for Transactions can take the guesswork out of the process or eliminate it altogether. The product currently supports three different vehicles for notification:
Also, notification conditions can trigger scripts that you can configure to resolve common application problems, such as restarting a COM+ Application, removing a server from a cluster, or integrating with your in-house management systems. Monitoring Transaction Performance Using Thresholds Let's walk through a typical sequence of events when AppMetrics for Transactions is configured to function as an early warning system and a problem occurs with a particular business transaction. 1. A system administrator receives an email stating that a particular business transaction is taking too long to complete.
2. The System Administrator then opens the product's run-time UI. As the product monitors the COM+ servers, the UI displays exceeded Thresholds in red and any configured notification vehicles get triggered. In this case, the Sell Stock Action Named Transaction is taking longer than the threshold originally anticipated.
Note: The AppMetrics For Transactions security model is based on Windows 2000 and Windows 2003 domain authentication. Therefore, one can easily control who has access to administer the product and who can access the run-time UI and historical reports. Also, the management console can be installed on one's desktop and remotely configure the servers where AppMetrics for Transactions is deployed, without compromising access to any features. 3. The System Administrator then examines the threshold originally set for the Sell Stock Action transaction. As configured, the Sell Stock Action transaction has a Duration Benchmark of 4 seconds. If the average duration of the transaction during a 60 second interval takes longer than 3 seconds (a threshold of 75%) notification is triggered. Since the average duration exceeded 3 seconds, he received the email notification.
So, just what are Named Transactions? Developers often assign names to components, methods, and ASP pages that are difficult to follow when viewing the business application as a whole. AppMetrics for Transactions gives system administrators the ability to layer meaningful names over operations involving COM+ components. These abstractions are referred to as Named Transactions. The Sell Stock Action Named Transaction corresponds to the lifecycle of the first method invoked on the Broker component instantiated from the Active Server Page (ASP) page SellStockAction.asp. The Last Recording fields display the Aborts, Starts, and Duration when monitoring was last stopped. This is helpful as you decide upon reasonable thresholds. As the product monitors and Warning levels are crossed the UI displays yellow. When Notification levels are crossed it displays red and any configured notification vehicles get triggered. Benchmarks can be set against transaction Aborts, Starts, and the Average transaction duration in an interval. (By default an Interval is 60 seconds but this can be reset.) 4. Now aware of the problem, the system administrator can begin to diagnose it and examines the performance reports for the time period in question. AppMetrics for Transactions contains a number of out-of-box reports that run in Microsoft Excel and display Transaction Rate (Started, Completed, Aborted), Transaction Duration, and DTC Transaction Time (the duration spent in the Distributed Transaction Coordinator).
5. After examining the performance reports the system administrator can clearly see that the Sell Stock Action transaction is consistently taking longer than was anticipated. Recognizing that it's not simply a fluke, the system administrator feels justified in escalating the issue, pulling in more resources to hunt down the cause of the high transaction durations. Customers haven't complained about the problem yet - they're waiting a few seconds to sell their stocks, but their trades are executing. However, the System Administrator has caught a potential forest fire at the first sign of smoke since he knows the component in which the problems are manifesting themselves. As a result, the development team can efficiently track down the cause with minimal impact on the business. Monitoring Package/Application Resource Consumption Using Thresholds The product's early warning features let you set Thresholds on resource consumption for individual COM+ Packages/Applications. This differentiates AppMetrics for Transactions from other monitoring solutions that simply monitor the aggregate resource usage across Packages/Applications. Tying resource consumption to specific Packages/Applications makes one's early warning system much more effective because when there's a problem, such as a memory leak, you get notified to the source of the problem. AppMetrics for Transactions can monitor the following resources:
For example, in the graphic below, the Threads Notification Level is set to 35 for the FMStocks COM+ Application. As configured, if the Application uses more than 35 threads, notification will be triggered.
At runtime, if a threshold is crossed, any configured Notification vehicles get triggered (such as email).
The production reporting features in AppMetrics for Transactions let you view throughput and resource use over a specified time period. This can help you demonstrate that Service Level Agreements are being met. Furthermore, contrasting reports for one period against another period can be useful input to your capacity planning process. The product archives data collected and correlated in a SQL Server database. Microsoft SQL Server 2005 or 2008 is required. All editions except for SQL Express and Workgroup editions are supported. Reports display in Microsoft Excel 2003 and later versions.
Top Ten Transactions Consider the transactions taking place within your system: the most expensive are not necessarily those that run longest. For example, transactions that take a full second but are rarely called are often less of a concern than those taking a half second, but called frequently. The AppMetrics for Transactions reports explicitly address this issue. The Top 10 Transactions chart sorts and lists transactions by multiplying each transaction's average duration by the number of starts per period. Using this formula, the Top 10 Transactions chart provides a listing of those transactions taking the longest to complete and called most frequently. Such a chart gives system administrators a high-level perspective of where the action is on their COM+ servers. What's more, Named Transactions carry over into the charts. For example, the Sell Stock Action Named Transaction displays. This makes it easier for those less familiar with the underpinnings of the COM+ component's code or object model to view the charts in terms of business operations.
Top Ten Components The Top Ten Components chart lists components taking the longest time to complete and called most frequently. Like the Top Ten Transactions chart, the Top Ten Components chart gives system administrators a high-level perspective of where the action is on their COM+ servers. If business-critical components appear in this list it might be worth spending resources to reduce their durations.
Package/Application Resource Use Over Time The Applications report displays Package/Application resource use over the specified time period and includes metrics for resources such as CPU, Memory, and Threads. Contrasting these numbers from one time period against another can often prove useful during the capacity planning process. Such numbers can also be useful when diagnosing suspected problems with an Application/Package such as:
Transaction Performance Over Time After viewing the Application reports to get a sense of which Applications/Packages are especially active, you can drill down into specific Transactions to view their individual performance. The reports display Transaction performance over the specified period, including:
These metrics are of benefit when troubleshooting problems because they give insight into what's really going on in one's Packages/Applications and Components.
Method Performance Over Time Method performance charts depict method call frequency and duration. Like the Transactions charts, these charts are of benefit during capacity planning and when troubleshooting problems because they give insight into what's really going on in one's Packages/Applications and Components. Suspected problems can be hunted down by examining activity and duration for each method in a component. Note: Since method activity during a period is reported, the fact that a method wasn't called during a particular period gets reported as well. This information is often useful during troubleshooting.
Each of the Production Reporting features discussed earlier can be useful when isolating problems because they enable you to contrast current performance and throughput against historical performance and throughput. But AppMetrics for Transactions also offers diagnostic features that make it easier for system administrators to zero in on trouble in COM+ Packages/Applications and Components at runtime. The combination of Production Reports and runtime UI can help you narrow problems down to specific components and methods. This can jumpstart the investigation process as problems get escalated to development, leading to quicker resolution and better application performance. Diagnosing a Problem Component Assume the Sell Stock Action Named Transaction, used in previous examples, starts taking longer than expected to complete and AppMetrics for Transactions triggered an alert sending email. At this point, any additional information the system administrator can glean from the COM+ system will be useful so development can simulate conditions and isolate problems with the transaction. 1. After receiving a notification, the system administrator explores current resource usage on the COM+ server. The product's UI displays information about each Package/Application. The system administrator notices that CPU usage for the FMStocks Application is exceeding fifteen percent. He also notices that the FMStocks Application has crashed at least once since he started a monitoring session.
Note: Without AppMetrics for Transactions, it is very difficult to map resource usage to COM+ Application/Package using only the tools provided by Microsoft. The MTS Explorer doesn't display the Process ID (PID) for active Packages, so one cannot identify which MTX.EXE in the Task Manager corresponds to a particular Package. The COM+ Explorer makes such a PID available, but in order to associate a PID with a DLLHOST.EXE instance, one must painstakingly search for it. To complicate matters, the PID can change anytime the Application gets restarted. 2. The System Administrator then examines which components are In-Call to get a sense of current activity for the FMStocks_Bus.Broker Component (which he knows is the one used for a Sell Stock Action Named Transaction). The FMStocks_Bus.Broker Component has several instances currently active.
3. The System Administrator then examines which methods are In-Call.
AppMetrics for Transactions lets him see that the SellStock method was called on the FMStocks_Bus.Broker Component. 4. The system administrator then uses the product's reports to contrast the historical performance of the Application and each of its Components against what he's seeing currently. For example, he could contrast performance of the SellStock method on the FMStocks_Bus.Broker Component for this morning, the past week, and the past month (as shown in the section “Method Performance Over Time,” earlier). 5. Development can then use the AppMetrics "Drill-Down" reports to trace the logical flow of method activity in sequence. 
The “Drill-Down” reports make bottleneck detection easy because they show:
Next Steps To see more AppMetrics Reports, please visit http:/www.xtremesoft.com/solutions/atx_reports.htm.
|
|
|
          |
|
|
|
|||||
