Network health - Careful application

As if there wasn't already enough to monitor and analyse,that they need to be monitored ever more closely. applications have now become the essence of our businesses. It is therefore becoming increasingly important to maintain consistent application performance.

Not so long ago applications were almost exclusively run on the desktop.

It was only the data that was being sent over the network - and the odd e-mail - that was stored on a central computer. The client/server revolution brought about the network-centric model of computing and now distributed applications are popping up everywhere.

With so much traffic eating up the available bandwidth, the applications running over the network slowly grind to a halt. It's only when users start complaining, that you realise something is wrong. Proper management therefore becomes increasingly important.

"With the increasing reliance on distributed networked applications (for example, e-mail, SAP, Oracle, etc), more and more of our customers are requiring visibility into not just network performance, but more importantly, application performance," said Andy Byrne, INSoft product manager, International Network Services.

"Most of our customers that are focused on application performance management want to monitor more than one application," he said. "They are looking to provide one set of business-oriented metrics, that they can apply to all their applications. And what better metric to use than capturing 'real' application transactions from the end user's desktop?"

"The key measurements of application performance are basic response time and critical health indicators," said Godfrey Jordan, UK OpenView marketing manager, Hewlett-Packard. "These must be linkable to business metrics, along with additional information for drill-down root-cause analysis."

Where you choose to monitor application performance will further dictate the hardware/software components needed for successful management. The server is a good place from which to measure because it is one end-point of a client/server transaction. This provides good visibility into applications because any encryption and tunnelling is removed by the time traffic reaches it. And if there are any 'backend' connections that the server masks from the client - for example, a web server accessing a mainframe - the server instrumentation might be able to characterise performance and availability in this area as well.

Server problems

There are some drawbacks to server instrumentation, however. One problem is that a server normally handles a lot of transactions from a lot of clients. Measuring this in real time is difficult and may have an impact on server performance.

If the server is running well, administrators may be reluctant to add further instrumentation to it - if monitoring adversely impacts the server a large number of clients may be affected. Furthermore, there is greater diversity in server operating systems and architectures than there is in clients. No single agent can instrument NT servers, Unix servers, mainframes and so on. Differences in operating systems and architectures also affect the type of data that can be extracted by an agent.

Finally, server instrumentation knows nothing about the network or client.

"If a client cannot reach a server, how can the server characterise performance for the application? Server instrumentation cannot tell us anything about the user's experience if the user can't access the server," said Byrne.

Another logical place to look at end-to-end application performance might be from within the network itself. If the network equipment breaks we will almost certainly need to look at a network agent. These are essential for network and data-link layer diagnostics and as troubleshooting tools once a problem has been isolated.

Instrumentation near the edge of the network begins to approximate the benefits of client-based instrumentation. But consider the case of a switched network to the desktop, where there would need to be a one-to-one correlation between clients and network agents to ensure full visibility. This could become an expensive proposition.

Byrne said that end-to-end application performance and availability monitoring should take place at the client. "There is no additional hardware expense associated with this solution. Because clients, for the most part, have standardised on Windows 95 and NT, a common desktop agent can be deployed.

Each client tracks its own transactions, so there are far fewer to track than on a server, and by measuring from the client we have a direct view of end user response times even when particular network segments or servers are not available."

NetIQ, on the other hand, takes a more server-centric stance. "We specifically focus on the server, both application and hardware performance," said Peter Stevens, spokesman for NetIQ. "At a hardware level we integrate with a variety of management applications, providing event correlation between the underlying hardware and NT. The next level we provide is ensuring that NT is functioning correctly by seeing that CPU and memory is not consumed by rogue processes. We then provide specific monitoring for a range of server-based applications."

"Application performance management is a two-dimensional challenge," said Jordan. "You need both RMON probes and device agents to be successful."

"RMON has inherently been used as the 'smoke-detector' of the network, giving statistics on layers two to four," said Owen Rounthwaite, senior systems engineer at Optimal Networks. "And with the standardisation of RMONII, it traverses all seven layers."

Byrne, however, disagreed: "VPNs and switching make RMON technology very expensive and, in some cases, obsolete. You are unable to glean performance metrics from the end user's perspective."

"Polling or probe-based monitoring, by its very nature, puts an overhead on the network infrastructure whenever the probe is active," said Stevens.

Device agents, however, allow you to monitor and gather metric data without producing any unnecessary overheads. Data can be saved locally by the agent and uploaded to the central database at a time of low network use.

However, Rounthwaite sees the device agent quickly becoming the bane of many network specialists. "Nearly every solution requires a proprietary agent to collect the statistics and send them to the console on demand," he said.

Agents allow the console to understand how the application affects the network. They can then find out if the fault is with the network or with the application.

Not all application performance management applications, however, are the same. "Some vendors just do response time monitoring on the desktop," said Byrne. "We call this stop watching." While this is a good way to monitor application performance on its own, it does not point to where the application is having problems.

"Fast desktop application performance, in a client/server or thin client-based application, is an indication of good underlying network performance," said Stevens. "However, poor desktop performance for the same applications does not necessarily indicate poor network performance."

Drill-down capabilities

"The issue could also lie with the underlying database or operating system, hence a requirement for drill-down capabilities within the application," added Jordan.

Although it is information at layers four to seven of the OSI stack that we are interested in, it becomes increasingly important to understand the underlying network infrastructure as it enables us to understand why the performance is as it is.

"Generally, layers four to seven are the most important, but the pressure from our customers involves having visibility into all seven layers," said Byrne.

Today's advances have created more problems. "It has become harder to locate the problems," said Rounthwaite. "With distributed object technology and multi-tiered applications, where do you start?"

"There are many business-critical applications and the number keeps expanding: SAP R3, PeopleSoft, Lotus Notes, Microsoft Exchange, intranet, internet, and mainframe access to name but a few. What single tool can report on all of them?" asked Byrne.

Lan switching, remote access and VPNs have created a number of dramatic performance increases but have also led to decreased manageability and visibility.

Changes in the market and in technology now make client-end management possible, while standardisation on Windows as the client OS and TCP/IP as the protocol stack produces a ubiquitous platform for deployment. Pentium processing power and low memory costs make it easy for us to deploy a 'low impact' agent without affecting performance.

"Application performance and availability must be measured from the client because that perspective is the most valuable," said Byrne. "It allows us to measure exactly what the user sees in terms of performance and availability."

Whether you approach application performance management from the server or client end, there's no denying the simple fact that as applications become increasingly critical to the workings of our business, maintaining consistent and acceptable application performance is vital.