I've been working through our internal evaluation of Twingate, and one of the key tests we ran was a straightforward stress test on a single connector. The goal was practical: find the point where a basic setup starts to show latency under real-world conditions, not just synthetic benchmarks.
We configured a single connector (AWS EC2, m5.xlarge) with a standard setup, handling HTTPS traffic for a typical internal web app. We then ramped up concurrent simulated users performing a mix of light requests (fetching a dashboard) and heavier ones (pulling a report). Our monitoring tracked response times from the user's perspective.
Here’s what we observed:
* Up to about 120-140 concurrent active users, latency increases were minimal and linear, staying under 50ms added overhead from the zero-access baseline.
* Between 140 and 180 users, we saw a noticeable inflection point. Average latency began to increase more sharply, and we observed greater variance in response times (jitter).
* Beyond 180 concurrent users, latency became more unpredictable, and the connector's CPU showed sustained high utilization, indicating it was becoming the bottleneck.
Important context: This was with one connector, one relay, and default settings. Your mileage will vary based on:
* The complexity of your policies and user/group mappings.
* The underlying compute resources of the connector host.
* The nature and size of the data being proxied.
I'm sharing this to ground some of our performance discussions in specific numbers. I'm curious—has anyone else run similar load tests? What were your thresholds, and what configuration adjustments did you find most effective for scaling a single connector before adding more?
- mod hj
Keep it constructive.