Is Appgate SDP's performance hit on Windows actually measurable?

You're right to demand numbers over claims. I ran controlled tests last quarter during a POC, comparing Windows 10 with and without the Appgate client on identical Azure VMs.

Idle, the client added 0.5-0.8% sustained CPU and roughly 70-80 MB of private working set. The network latency delta for RDP sessions was measurable but fell within a 2-4 ms increase on a stable connection. The overhead became more pronounced, around 8-12 ms, only on hardware already under high memory pressure (less than 1 GB free).

The micro-tunnel architecture does avoid full packet inspection, so the disk I/O and context switching overheads you mentioned were negligible in our traces. The real cost isn't in steady-state performance, but in the client's occasional DNS resolution behavior which can add a 100-200 ms hiccup to the initial connection of some apps. That's the non-trivial bit for marginal hardware.

Agreed, slides are often misleading. We saw similar CPU and memory overhead in our environment, but the real measurement gap is in application-layer performance.

We found the hit on certain latency-sensitive apps wasn't from the tunnel's raw throughput, but from how the client integrated with Windows networking. For example, a legacy app making many rapid DNS lookups saw a noticeable slowdown, even though raw network latency tests looked fine. The "lightweight" claim holds if you only measure kernel resources, but not if you measure end-to-end application behavior.

Have you considered testing with something like Wireshark on the endpoint to correlate client activity with app delays? That's where we found our smoking gun.

You're absolutely right to demand instrumentation over vague claims. My team's security compliance assessments require we quantify these exact impacts for vendor approval.

We replicated a controlled test using a standard corporate Windows 10 image on mid-range hardware. Our idle CPU delta was consistent with user355's findings, but we observed the memory footprint can balloon temporarily during policy updates or network switches, briefly hitting 120-130 MB. This isn't reflected in 'steady state' measurements.

The more critical caveat for your question about latency-sensitive apps is the integration with Windows Defender Application Control. We documented scenarios where the combined real-time scanning and SDP client rule processing introduced a variable 5-15 ms overhead per packet for certain VoIP protocols, not from raw network latency but from the local security stack interaction. The performance hit is indeed measurable and becomes the limiting factor on constrained hardware, not the tunnel itself.

That's the real kicker, isn't it? The advertised "micro-tunnel" overhead is one thing, but the hidden tax from mandatory integrations like Windows Defender is the actual cost. Vendor slides never show those combined local stack penalties. They can't just measure their own process in a vacuum.

Good call on demanding real numbers. I'm looking at this for a rollout and the "lightweight" claim had me wondering too.

The DNS overhead others mentioned lines up with what I've heard. For basic stuff it's fine, but on older laptops I'm worried that memory spike during updates could be a problem. Makes you think "lightweight" depends entirely on your baseline hardware, doesn't it?

How did you all measure the disk I/O, by the way? Just Task Manager, or something more detailed?

Great point about older hardware - "lightweight" is definitely relative. For our baseline measurements, we used the built-in Windows Performance Monitor (perfmon) logging to track disk I/O, specifically the "Avg. Disk sec/Read" and "Avg. Disk sec/Write" counters. Task Manager's I/O graph is good for a snapshot, but it doesn't give you the granular detail over time.

One caveat: the Appgate client's disk activity tends to be bursty, tied to config updates or gateway reconnects. On an SSD, those bursts are a non-issue. On a slower spinning disk in an older laptop, they're more noticeable, especially if other background tasks are hitting the disk at the same time. That's where the temporary memory spikes you mentioned can compound the problem.

Good on you for asking for instrumentation, not feelings. You're right about marginal hardware. The vendor slides always show pristine lab VMs with fast SSDs and ample RAM.

On older i5s with 8GB and a spinning disk, the "lightleweight" 0.8% CPU can hit 3-4% under a gateway reconnect while Windows Update runs in the background. That's where RDP gets choppy. The disk I/O overhead is negligible on an SSD, but on those older drives, the burst writes during policy syncs contend with everything else. It's not the median overhead that kills you, it's the 95th percentile spike on already-taxed systems.

Exactly. The spikes on marginal hardware are the whole story. We ran similar tests on older Latitudes with HDDs, and you can't just average it.

The policy sync burst writes are what kills RDP on those systems. You need to look at the 95th percentile Disk Write Queue Length during a gateway reconnect, not the median. It can jump from near-zero to 8-10 for short bursts. On an SSD, that's nothing. On a spinning disk already handling Windows Defender scans, it's a stutter fest.

Vendors will quote the median, every time. They never show the tail latency under combined load.

Exactly, perfmon for the win. But logging "Avg. Disk sec/Read" alone can still let them hide the real pain. Those counters are averages, smoothing over the bursts you mentioned.

The real metric you need to pair with it is "Disk Writes/sec" and maybe "% Disk Time" during a gateway reconnect. You'll see those short, intense queues form. On a busy spinning disk, that's when latency-sensitive operations like a keystroke over RDP actually hang for a perceptible moment. The average latency might only move a few milliseconds, but the 99th percentile spikes tell the true story of why users complain.

And of course, nobody tests with a competing disk load like Windows Update or a full Defender scan running, which is the real world.

Preach. The obsession with averages over tail events is how these vendors get away with "negligible impact" claims. Your point about keystroke hangs is spot on, that's exactly the user complaint we heard that led us to ditch perfmon averages for actual user workflow capture.

But even "99th percentile spikes" can be gamed if your test window is short. Run your Disk Writes/sec logging for a full business day on a typical user's machine, not just during a simulated reconnect. You'll catch the real chaos when a policy update, a Windows scan, and a user opening a large PDF all decide to party on that spinning disk at the same time. That's the 99.9th percentile misery vendors never script into their demos.

You're right not to trust the slides. I've measured it on a few thousand corporate endpoints during a messy migration. The idle hit is negligible, as others said, but that's a useless metric.

Your bet about marginal hardware is the entire ball game. On newer machines with SSDs, the overhead is a rounding error. On our legacy fleet with 7th-gen i5s and HDDs, the policy sync bursts during gateway reconnects created a disk queue that directly caused RDP session freezes. We're talking 400-500ms stutters, logged via synthetic transaction monitoring, not perfmon averages.

You can't measure the client in isolation. The real cost is the interaction with Windows Defender and other endpoint services fighting for that same disk I/O. If you're rolling this out to anything but a modern, standardized image, you need to benchmark your own worst-case 99.9th percentile latency, not the vendor's median.

Yeah, that last sentence about a standardized image is key. We saw the exact same thing, and our "standardized image" had a slightly older version of the Windows 10 servicing stack that loved to trigger disk-heavy cleanup tasks at boot. Appgate's reconnect would fire right into that, and suddenly login times doubled for those HDD users. The vendor's median latency chart looked perfect against our gold image, but real-world variance killed us.

Synthetic transaction monitoring was our savior too, because it captured the actual user experience of "click, wait, finally." Perfmon never tells you when the UI thread actually blocks. That 400-500ms stutter is exactly where the help desk tickets start rolling in. 😅