Version

Argent Advanced Technology all versions

Date

Tuesday, 26 Nov 2013

Summary

Customer may notice high bandwidth usage when Argent AT Engine is running Windows Performance Rules against remote machines

Argent AT deployment should be considered carefully when the bandwidth usage is a concern

Technical Background

Argent AT uses Microsoft PDH library to retrieve performance data from Windows Servers

When the Monitoring Engine process connects to the remote machine for the first time, for a typical Active Directory implementation, about two to five megabytes of data are exchanged by the Microsoft handshake

This is normal behavior required by the Microsoft Windows security model

After the Argent Monitoring Engine process has established the PDH connection to remote machine, subsequent PDH APIs will cause very little traffic

But if the connection is dropped because remote machine is no longer available, or the Argent Monitoring Engine process restarts, the two to five megabytes of data exchanged by the Microsoft handshake will re-occur when a new PDH API is called on the remote machine

This is generally not a concern as the target machine is most likely in the same gigabit network as the Argent AT Engine

But it is a different story when the remote machine resides at a remote network linked with Argent AT Engine with a slow and unreliable network connection, and there may be other applications using the same link

When the re-occurring Microsoft handshakes consumes too much of the bandwidth, other applications can suffer

Resolution

As the initial data exchange is part of Windows security model, this cannot be avoided

But the Argent AT architecture and configuration can be optimized to deal with the slow link

Scenario 1 – Remote Office With Over 30 Servers Or Devices To Monitor

The Argent Mother/Daughter architecture is recommended when the remote office has more than 30 servers or devices to monitor

By deploying an Argent Daughter Engine at the remote site, the data exchange for initial PDH connection happens within the remote LAN; no such data need to cross the slow link to the main office.

Scenario 2 – Remote Site Or DMZ With Under 30 Servers Or Devices To Monitor

An Argent Trusted Agent architecture is recommended when the remote site has fewer than 30 servers or devices to monitor

In the extreme case there is just one server in the remote site or DMZ

The Argent Trusted Agent can be deployed right into this server

Again, the initial PDH data exchange happens within the remote site or DMZ, no bandwidth cost to the slow link to the main site

Scenario 3 – Customer Does Not Want To Deploy Either Daughter Engine Or Trusted Agent

This case is less than ideal, but optimizing the configuration can minimize the pain

The Relator containing the Windows Performance Rule and remote machine should use fixed shared pool

It does not have to be pool#1, just do not use ‘Dynamic‘ or option ‘Spawn New Monitoring Engine Process‘

By doing so, the same Monitoring Engine process can cache the PDH connection to the remote machine

The first time still incurs Microsoft handshake overhead, but subsequent executions of the rule will cost little