Skip to content
Notifications
Clear all

Anyone else seeing high CPU on connectors when using certain legacy protocols?

2 Posts
2 Users
0 Reactions
5 Views
(@brianl)
Estimable Member
Joined: 1 week ago
Posts: 113
Topic starter   [#9361]

Hello everyone,

I've been evaluating Zscaler Private Access for a potential deployment in our manufacturing environment, where we have a mix of modern cloud applications and several legacy on-premises systems. I've been conducting a proof-of-concept with a handful of connectors, and I've noticed a recurring pattern that I wanted to ask the community about before proceeding further.

During our testing phases, specifically when accessing internal systems that rely on older protocols like SMBv1 or certain proprietary TCP-based industrial protocols, we observe a significant and sustained spike in CPU utilization on the relevant connector VMs. The CPU usage can jump from a baseline of 10-15% to 70-90% for the duration of the session. This does not seem to happen with HTTP/S or even standard RDP traffic, which remains very efficient.

My background in ERP and inventory management systems means we often have to interface with older warehouse management or shop floor data collection servers that haven't been modernized. The security model of ZPA is very appealing for these use cases, but the resource overhead has me concerned about scaling. We would potentially need to support hundreds of such connections concurrently during shift changes.

I have reviewed the available documentation on connector sizing and the note about protocol processing overhead, but the guidance seems quite general. I am trying to gather more concrete data.

Has anyone else in the community, particularly those in manufacturing or logistics with similar legacy system landscapes, observed this behavior? I am curious about a few specific points:

* Is this high CPU load primarily during the data transfer phase, or is it also high during idle connections for these protocols?
* Have you found any specific configuration adjustments on the connector, application segment, or server access policy level that mitigated this, or did it primarily come down to provisioning more powerful connector instances?
* Does Zscaler provide any more granular guidance on estimating connector capacity when a significant portion of the traffic profile consists of these non-HTTP legacy protocols?

I want to ensure our architecture is sound and cost-effective before moving forward, as over-provisioning connectors could change the business case. Any insights from your own reviews or production experiences would be greatly appreciated.



   
Quote
(@jamesr)
Trusted Member
Joined: 1 week ago
Posts: 48
 

Interesting. We saw something similar a few years back when testing a different ZTNA solution with older industrial protocols. In our case, it turned out the protocol itself was extremely "chatty," sending tons of small packets, and the encryption/decryption overhead on the connector was murder on the CPU.

Have you checked the packet capture or network stats on the connector during one of these sessions? That might tell you if it's a processing load from handling a flood of tiny frames, which could point to a sizing or tuning issue rather than a pure protocol problem.

What VM size are you running for the connectors in your PoC? I'm wondering if bumping to a higher CPU count just for the connectors handling these legacy systems might be a temporary workaround, even if it's not ideal.


Just here to learn.


   
ReplyQuote