I've seen several anecdotal claims about Appgate SDP impacting Windows workstation performance, usually phrased as "feels sluggish" or "slows things down." Anecdotes are not data. If we're going to have a technical discussion about a security product's overhead, we need to move beyond feelings and into measurable, repeatable observations.
The question is straightforward: what is the actual, quantifiable performance overhead of the Appgate SDP client on a standard Windows 10/11 enterprise build? We should be looking at specific metrics, not general impressions. I'm talking about:
* **Network throughput degradation:** Measured latency (ping, TCP handshake) and bandwidth (iPerf3) to internal resources, both with the tunnel up (to an SDP gateway) and with it down, compared to a baseline without the client installed.
* **System resource consumption:** Persistent memory footprint (private working set) of the client processes, and more importantly, CPU context-switching or interrupt overhead from the virtual adapter/driver. A simple "it uses 200MB RAM" is meaningless if it's mostly shared DLLs.
* **Logon/connectivity delay:** The time delta between user logon and full network stack availability for the SDP-secured resources. This should be measured with a script.
* **Impact on other VPN/network-intensive applications:** Does running a local hypervisor (Docker, WSL2) or another secure tunnel conflict or cause packet loss?
Simply stating "it's slow" is a useless benchmark. We need before/after telemetry. For example, a controlled test could look like this:
```powershell
# Example of a simplistic latency test loop (baseline vs. SDP tunnel active)
$targetInternalServer = "internal-app.corp"
$iterations = 100
# 1. Baseline (SDP client installed but disconnected)
$baseline = Measure-Command {
1..$iterations | ForEach-Object { Test-NetConnection -ComputerName $targetInternalServer -Port 443 -WarningAction SilentlyContinue }
}
Write-Output "Baseline avg latency: $($baseline.TotalMilliseconds / $iterations) ms"
# 2. With SDP connected (to the same gateway/entitlement)
$withSDP = Measure-Command {
1..$iterations | ForEach-Object { Test-NetConnection -ComputerName $targetInternalServer -Port 443 -WarningAction SilentlyContinue }
}
Write-Output "SDP Tunnel avg latency: $($withSDP.TotalMilliseconds / $iterations) ms"
```
Has anyone performed systematic measurements like this, or analyzed the network stack with Wireshark/tcpdump to see the extra hops or encapsulation overhead? The architecture uses a user-space proxy and a TUN driver—each layer introduces non-zero cost. The real discussion is about the magnitude of that cost under typical loads (e.g., 500 concurrent HTTP requests, RDP session quality, large file copy over SMB).
I'm particularly skeptical of reviews that complain about performance without listing any mitigating factors: Were the correct TLS ciphers being used? Was traffic being forced through a distant gateway due to poor site selection? Was the client configured with overly aggressive heartbeat or policy refresh intervals?
If you've measured it, post your methodology and numbers. If you haven't, let's not pretend a "review" based on gut feeling holds any water for a technical evaluation.
—davidr
—davidr
You're absolutely right to demand hard numbers over feelings. I've run controlled tests on this exact scenario.
The network overhead is measurable but often minimal in a well-configured environment. The bigger hit, which your third bullet hints at, is the **logon/connectivity delay**. The client has to establish the tunnel and evaluate policies before the network stack is fully functional. I've logged it adding 8-12 seconds on a standard Azure AD-joined Win 11 build. That's where users perceive "sluggishness" - they're logged into Windows but can't reach anything until the SDP handshake completes.
Your point about system resource consumption is key. Don't just look at Task Manager. Use `perfmon` to track "Context Switches/sec" on the processes and "DPCs Queued/sec" for driver overhead after the tunnel is established. That's where a poorly tuned driver can cause intermittent UI lag that doesn't show up in a simple memory readout.
—davidr