While most network monitoring tools have spent years inexorably working their way up the protocol stack, a newcomer - PremiTech's Performance Guard - starts at the top and stays there. PremiTech says Performance Guard monitors client machines at the application layer to collect useful statistics regarding user experiences.

We recently tested Performance Guard Version 4.0 and it proved to be less a tool you occasionally reach for to solve a specific problem and more a measuring stick that continuously gathers and tracks client performance data, including application response times. We even found a use for Performance Guard that its Danish designers perhaps didn't foresee.

View from the top
Performance Guard consists of a server component, agents you deploy on each client and a customer-supplied copy of either Microsoft SQL Server 2000 or the Oracle relational database. The server component, which includes its own Web server, gathers performance data from the agents and stores the result in the relational database. The server component runs on Windows Server 2000 or 2003, while the agents run only on Windows XP, 98, ME and client versions of Windows NT, 2000 and 2003. Performance Guard scales quite well, with a single-server component easily able to manage up to a few hundred clients.

Like any good asset inventory tool, Performance Guard reveals such client details as computer name, processor type and speed, type of network interface, installed RAM and hard disk size. It goes much further, however, to measure overall CPU and memory utilisation, I/O statistics, the names and owners of running processes, CPU and memory utilisation by process, as well as I/O reads and writes by process.

Performance Guard's client-based agents noted each client's server response time, along with the traffic densities and any network errors it experienced. Performance Guard also measured and categorised Web transaction activity (that is, HTTP-based application services) in our tests, based on transaction characteristics we specified at the Performance Guard Server.

Performance Guard comes with a handy Internet Explorer helper object that computes precise Web access response times and tracks the URLs that a client accesses. We could even configure each Performance Guard agent to use Internet Control Messaging Protocol echo requests/replies to ping specific servers and devices on the network. These pings provided client-oriented data that revealed client-to-device or client-to-server network access times. Impressively, Performance Guard collects performance statistics for Citrix Metaframe Server-based applications, including per-session data and server responsiveness.

Setting thresholds
For any Performance Guard-measured metric, we could specify a threshold, above which the server component would notify us, via e-mail or pager alert, that a problem had occurred. We also instructed Performance Guard to send alerts to IBM's Tivoli, Computer Associate's TNG network management systems and the help desk tool Remedy.

Performance Guard cannot automatically fix problems. For example, it cannot restart a Windows service or stop a runaway process. An administrator has to visit the client computer to manually correct problems.

The Performance Guard agents are small and resource-frugal. Each one, typically consumed less than one percent of the client's CPU, and often less than half a percent. Each agent sampled performance at predefined intervals. The default interval is one second for local performance metrics, such as CPU and memory utilisation. At the Performance Guard server, we could specify each agent's sampling rate, from 1 second up to 60 seconds.

Each agent collects data for a reporting interval, which we could set from 10 seconds up to 2 minutes. The reporting interval governs how much bandwidth the agents use to send data back to the Performance Guard server. While a short interval implies high-resolution statistics, it also results in higher bandwidth utilisation. Similarly, a long interval implies low-resolution statistics and low bandwidth utilisation. PremiTech suggests setting the reporting interval to between 30 and 120 seconds, but we found an interval of 20 seconds did not adversely affect our network traffic. Setting the interval to 20 seconds (that is, three transmissions to the Performance Guard server every minute from every agent) sends 18,000 reports per hour over the network for 100 clients. Depending on whether we'd told the agents to collect optional statistics, such as ping timings, the 20-second interval setting caused Performance Guard agents to send a total of 6M to 14M bytes to the server each hour. The resulting bandwidth and server storage utilisation's were not burdensome.

Ease of use
Performance Guard has a browser-based interface consisting of a Java 2 Platform Enterprise Edition application server environment that uses Java Database Connectivity to access the relational database and that emits dynamic Web pages an administrator interacts with. The interface, with its self-explanatory menus and thoughtfully designed configuration windows, was easy to navigate. Setting up named groups of users (client devices) and then configuring each group was also simple.

Reports are particularly useful to detect response time problems by individual users or for groups of users. They were also useful for spotting trends.

We were able to use Performance Guard as a workflow measurement tool. Imagine a department of 30 heads-down data entry employees using a custom application. By defining that application's transactions at the Performance Guard server, we could view reports that quantified each data entry station's workflow and productivity. When correlated with the overall business workload, these Performance Guard client activity reports helped us better assess, for instance, when to hire people or which transactions were more difficult for people to handle.

Installing the agents across our Windows-based network was almost painless. Using Microsoft's MSI installer, the Performance Guard server component quickly and silently distributed agents onto our clients. Only when MSI fails (these failures can be rare or frequent depending on Windows versions, patches and configurations), or when a client isn't powered on during installation, will you have to visit specific clients to manually install the agent. Unfortunately, the documentation is a set of online PDF files.

Barry Nance runs Network Testing Labs and is the author of Introduction to Networking, 4th Edition and Client/Server LAN Programming.


Performance Guard does for clients what traditional monitoring tools do for servers. If you have a specific application crying out for client-side response-time monitoring, or if you want to track office workflow from the application's perspective, Performance Guard might be what you need.