Optical Prime Performance Impact on Local and Remote Windows Servers

David Hunter

- Live Optics Collector

Optical Prime uses the default protocols exposed by operating systems to collect configuration and performance data.  Collecting data from a server has virtually no impact on the server’s CPU, memory, disk, and network resources.

If a single collector process is connected to a large number (50 or more) remote servers, the collector will begin to use a small but noticeable level of CPU and memory.  This is especially true when using the Linux collector, as it will spawn an SSH process for each remote connection.

It is not necessary to run the collector on a Production Server as the collector can remotely monitor the production servers.


-Collection: Local/Remote

For local Windows collection, the collector uses the Microsoft PDH protocol and other Windows system API calls. These are the same performance counters that Microsoft PerfMon accesses.

The PDH protocol also could be used for remote collection. However, this protocol is not sufficiently secure when used remotely. So, for remote collection, the collector uses the remote WMI protocols. 

We are unaware of any cases where using Optical Prime has been confirmed to cause performance issues on a local or remotely targeted system. 

Since 2008, five cases have been reported from the field where users complained that remote WMI collection from Optical Prime caused problems with their Production Windows Servers.  Over that same time-frame, Optical Prime has collected millions of production environments.  We investigated each case, and none were proven to be related to Optical Prime.  Our opinion is that out of millions of runs, one is bound to coincide with an unrelated incident.  Understandably, the natural reaction is to initially blame whatever is new (such as Optical Prime running).

Optical Prime utilizes standard WMI data calls from Microsoft for remote captures.  

Win32_ComputerSystem, Win32_DiskDrivePhysicalMedia, Win32_DiskDriveToDiskPartition, Win32_DiskPartition, Win32_LogicalDisk, Win32_LogicalDiskToPartition, Win32_NetworkAdapter, Win32_NetworkAdpaterConfiguration, Win32_OperatingSystem, Win32_PerfRawData_PerfOS_Processor, Win32_PerfRawData_Tcpip_NetworkInterface, Win32_PhysicalMedia, Win32_Processor, Win32_SystemEnclosure, Win32_PerfRawData_HvStats_HyperVHypervisorLogicalProcessor, Win32_PerfRawData_PerfDisk_PhysicalDisk,  Win32_PerfFormattedData_PerfDisk_PhysicalDisk, MSCluster_Disk, MSCluster_DiskPartition, MSCluster_DiskToDiskPartition, and StdRegProv are examples.

Microsoft has acknowledged dozens of problems with WMI over the years and incorporated their fixes into service packs and OS updates.  Our recommendation is that users keep their operating systems fully patched to minimize risks.

Was this article helpful?
3 out of 3 found this helpful
  • 0

    Amr hafez

    Thank you David, it is a good reference

    Comment actions Permalink
  • 0

    Yessica Zamudio

    Great explanation

    Comment actions Permalink
  • 0

    Chris Dunning

    Good stuff David.  What about the impact on ESXi hosts?


    Comment actions Permalink
Please sign in to leave a comment.