InformationWeek
Defining The Business Value Of Technology
|
January 29, 2001 |
 |
Application Performance Management
The Well-Mannered Application
The distributed nature of E-commerce applications requires better and more precise measurements for performance and reliability. The advent of ASP-provided applications adds yet another wrinkle to the application performance challenge.
By Steve Steinke, Network Magazine
| More on application management: |
|
|
 Send Us Your Feedback |
t's hard enough to get networked applications deployed and running. But increasingly, the performance of crucial applications needs to be monitored and controlled.Two trends are propelling and complicating the need for performance management. First, the near ubiquity of the Internet Protocol and the declining cost of network throughput make application outsourcing more feasible than ever. Second, many critical apps are distributed across multiple architectural tiers and independently controlled networks.
The implications of these trends warrant examination. Companies may choose to turn over components of their applications to application service providers, management service providers, or some other sort of service company.
However, service providers will rarely be able to justify taking over an application crucial to their enterprise customers without negotiating a service-level agreement. A traditional SLA, such as one used for frame relay or Internet connectivity that specifies aggregate measurements like uptime averaged over a month, won't do. The service-level agreement for a specific critical application must be detailed and granular.
Certainly, applications need to be available. But the sort of availability that, say, an Internet service provider might guarantee--for instance, 99.7% uptime for the month--tells you very little about the customer experience. Those 2.16 hours (0.3% of 30 days) of downtime may be at peak demand times, or they may coincide with users' most important deadlines. In many circumstances, average monthly uptime is inconsequential to users.
One of the most commonly desired requirements for applications is a short and predictable response time. A few ISPs are willing to include latency in their SLAs, though they generally restrict the circumstances to such an extent that the guarantee has little value. Most commonly, only traffic that remains on the ISP's network is guaranteed. In addition, it's a common practice to average latency measures over periods as long as a month, which, like the gross availability measure, may correlate imperfectly with real-time user experiences. Useful response-time measures should be taken as they occur and should be reported immediately, as well as averaged over longer periods.
Application users have a number of other service-level measures that provide a closer tie to their actual experiences than gross uptime or delay. For example, the percentage of transactions that run to completion may be more important than minor delays. It may be important to know percentages of customers that fill out complete forms and then abandon the transaction. The measurements that matter to a user in a real-time videoconference won't be geared so much to discrete transactions as to the details of factors such as latency and jitter. In many cases, some of the most interesting performance metrics are specific to a particular application. Not only are commonly guaranteed network performance specifications irrelevant to users, but generic application-layer performance specs may also fail to indicate acceptable performance.
While the increasing demand for detailed SLAs calls for client-centric management, the demand for end-to-end management requires insight into network elements and servers that may not be instrumented for performance measurement. New n-tier application architectures aren't necessarily rolled out with integrated management capabilities. Application servers that process the business logic of an application, database servers that feed data to the application server, load-balancing devices, firewalls, and virtual private network processors all may contribute to application degradation. Ideally, these devices should have granular performance-management capabilities.
The situation is further complicated for critical applications because many of these architectural components will be duplicated (or triplicated) for redundant operation.
Successful end-to-end performance management isn't the end of the struggle. Typically, transactions and other application events are only interesting as part of a business process. For example, taking an order from a customer is part inventory management, shipping, and accounts receivable. The aim isn't to manage a technical operation with servers, disk arrays, routers, and so forth, but to make business processes efficient and pleasant for customers, suppliers, partners, and employees.
Application performance management vendors have traditionally addressed three management techniques. One, with roots in the world of mainframe applications, is for programmers to insert markers or break points within apps. The performance statistics are written to a file or communicated to another program at each crucial step to be monitored.
The second technique involves sucking up all or selected parts of the traffic on the network, correlating requests with replies, and inferring application performance based on packet analysis.
The third technique installs a sort of parasitic agent alongside each client or, perhaps, on the same LAN segment as a group of clients. The agent looks at operating system-level events, such as opening windows and on-screen form submissions, and is either told or can infer what to measure.
The advantage of the programmed break point is that the original programmers know precisely what the right events for accurate and comprehensive instrumentation are, and there should be no doubt that the measurement is correct. Furthermore, the measurement can be as granular as needed.
continue on to page 2
Back to This Week's Issue
Send Us Your Feedback
Top of the Page
