Just finished a POC for a retail client with 50+ physical stores. Their back-office systems (inventory, timekeeping) needed secure, low-latency access from each location's management terminal. Perimeter 81 was a contender against a more traditional IPSec setup.
I was primarily brought in to measure the latency impact of the secure access overlay. The goal was sub-50ms added latency for transaction processing. Here's the baseline config template I used for each store gateway:
* **Gateway:** Deployed as a lightweight agent on the store's local server.
* **Network:** Assigned each store to its own dedicated network within the Perimeter 81 console.
* **Access Rules:** Zero-trust, application-specific. Only the back-office application IP/port was exposed, nothing else.
* **Observability:** Leveraged their built-in latency metrics per connected gateway.
Initial results were promising. The median added latency from the stores to the cloud-hosted back-office was around 22ms, which is acceptable. However, I noticed significant variance during peak business hours (10am-2pm local time). Some stores jumped to 45-50ms added latency, which started to affect the user experience.
I'm curious if others have run similar performance benchmarks, especially for distributed retail or branch office setups.
* Did you find the built-in metrics sufficient, or did you instrument further with your own monitoring (e.g., synthetic transactions)?
* Any specific tuning to reduce latency variance? I'm looking at playing with the encryption settings, but wondering about real-world trade-offs.
* How does this compare, latency-wise, to other SASE/ZTNA providers you've tested for similar use cases?
ms matters
That's super interesting about the latency variance during peak hours. It makes sense, but 22ms median is a great starting point.
What's the bandwidth situation like at each store during those busy periods? I've seen similar spikes when the local connection gets saturated with other store traffic, like POS data or security cameras uploading. The secure tunnel is competing for the same pipe.
Have you thought about setting up quality of service rules on the store's router to prioritize the traffic from the management terminal? That might help keep it consistent without needing a bigger circuit.
sales with substance
That's a really good point about bandwidth. The store circuits are 100 Mbps down / 20 Mbps up, which seems fine on paper, but the security camera upload is a killer. They're constantly streaming to cloud storage, especially during open hours.
I hadn't considered router QoS for this. That's a clever, simple fix. My worry would be misconfiguration - if someone resets the store router or the rules are applied wrong, the tunnel performance could fall off a cliff without an obvious alert. How do you typically monitor that the QoS is still active and working? A quick ping latency check, or something more involved?
rookie
QoS monitoring is the classic "set it and forget it" trap. You're right to be nervous.
Most consumer/SMB routers don't expose QoS status via an API you can poll. You're left inferring it from symptoms. I use a dual-pronged check: a constant, low-bandwidth UDP stream with strict latency thresholds (fails if QoS drops), and a separate alert if total outbound traffic exceeds, say, 80% of the pre-QoS reserved pipe. If that second one fires, you know something is eating the priority bandwidth.
But honestly, this feels like solving the wrong problem. You're adding router config complexity to 50+ locations to band-aid a bandwidth management issue. Can the camera upload be throttled or scheduled for off-peak hours instead? You're now managing security policies *and* network QoS rules across every store. One more thing to break.