Edge SWG Diagnostic Reporting: System Impact and Performance Considerations

Products

• ProxySG Software - SGOS

Issue/Introduction

In SGOS 7.4.11.1, the diagnostic reporting feature was introduced to diagnose issues related to sessions. You must have a minimum of SGOS 7.4.11.1 and SGAC 2.2.9 to use diagnostic reporting. Diagnostic reporting creates internal records that it uses to track session statistics for the following components:

• Sockets

• Sessions

• HTTP requests

Because diagnostic reporting uses system resources to create these records, system performance might be impacted. This article outlines how diagnostic reporting functions and its potential impact on the performance of the following metrics: 

• CPU

• Memory

• NetIO

• Latency

Resolution

When you enable diagnostic reporting, the Edge SWG appliance creates internal records to track the lifetime of the system component. The following table discusses how each component is tracked when diagnostic reporting is enabled:

Note: If the tracking monitor becomes overloaded, the monitor discards some record creation events. However, once a record is created, diagnostic reporting records all events for the component, even when the system is under a heavy load.

 

System Component	Tracking
Sockets	When a socket on the Edge SWG appliance is created, a record is created.
Sessions	When the Edge SWG appliance creates an active session (for proxied traffic), diagnostic reporting creates a record for that session. For some non-proxied sessions (such as DNS, ICAP, and access log sessions), diagnostic reporting also creates records.
HTTP Requests	When the Edge SWG appliance establishes an HTTP request, diagnostic reporting creates a record for that request. The HTTP request then associates itself with a session.

 

Performance Analysis

The following table further outlines the effects on the appliance.

System Component	Potential Performance Impact	Cause of Impact
CPU	Diagnostic reporting might require an entire CPU core to collect and record diagnostic records. If the system does not have enough CPU headroom to allow for diagnostic reporting, incoming request traffic might be impacted. When the appliance is under a heavy load of traffic with diagnostic reporting enabled, the overall CPU usage on the appliance could increase by up to 6%. This increase is equivalent to one core running at full capacity. Diagnostic reporting minimally interacts with the rest of SGOS.However, tracked objects are minimally locked, which ensures little impact on other processes.	A single process on the Edge SWG appliance handles all tracking operations (such as record creation and monitoring). The tracking monitor can consume up to 100% of a single CPU when traffic is heavy.
Memory	Diagnostic reporting consumes extra memory. For example, a test on a 200 GB appliance consumed 1 GB more memory than an appliance with diagnostic reporting disabled. To manage memory consumption, two limits have been set: Records have a limit of 10 million rows across all tables The database for tracking objects has a limit of 1 GB	All records reside in memory. The more records that exist, the more memory that diagnostic reporting consumes.
NetIO	So long as the appliance has sufficient CPU and memory, diagnostic reporting has a minimal effect on overall NetIO performance.	The asynchronous nature of the APIs that diagnostic reporting uses causes the effect to be minimal on NetIO.
Latency	Diagnostic reporting has a minimal effect on latency.	The appliance creates and updates records asynchronously, which minimizes the effects on latency. The minimal impact of latency might be caused by lock contention for posting asynchronous events.