This experiment reported approximately 30,000 established concurrent gRPC connections while clients sent intermittent requests. That count is a reported observation from the run. It does not establish healthy production capacity.
The investigation focused on how resource behavior changed as the persistent-connection population grew, rather than treating request throughput as the whole workload.
Reported setup
- Service: Linux VM with 2 vCPU and 2 GB RAM.
- Harness: k6-based test with persistent client sessions and a gradual connection ramp.
- Listed ramp stages: 1,000 → 5,000 → 10,000 → 20,000 → 30,000 connections.
- Traffic: intermittent requests, with frequency reported below 100 requests per minute.
Reported observations
- Established connections: approximately 30,000.
- CPU: described as low.
- Memory consumption: approximately 6.8 GB.
- Swap usage: approximately 20 GB.
The memory and swap counter definitions, collection scopes, timestamps and swap configuration are not documented in this account. The request frequency has no specified per-client or aggregate scope, and the connection-counting method is not recorded. These figures cannot yet be reconciled into a per-connection resource model. In particular, the 6.8 GB figure should not be read as physical resident RAM on the listed 2 GB VM.
The original narrative described memory increasing as connections accumulated. That points toward further investigation of resource use and connection state. The available record does not supply a measured growth curve or isolate a primary cause.
Established connections and useful work
A useful capacity result needs a defined workload, observation window and success boundary. It also needs completed-work latency, failures, timeouts and disconnects over that window. Those measurements are not reported here.
I would use the established count to guide a follow-up investigation, rather than use it as a service-sizing target. Low CPU and a large connection count leave the user's completed workflow unanswered.
A conceptual scale-out option
One architecture to evaluate distributes client connections across gateway nodes behind a load balancer, with backend services handling the work. The diagram illustrates that option. This account does not report a validated scale-out outcome or a comparison with other architectures; the established count does not define a threshold at which additional nodes are required.
What the next measurement record needs
- Run conditions: script and software versions, server and generator configuration, ramp timings, hold duration, and the achieved request workload.
- Count definitions: where connections were counted and how logical sessions, channels and transport connections were distinguished.
- Resource definitions: counter names, units, collection locations and timestamps, including separate server and load-generator views.
- Useful-work outcomes: completed-work latency, failures, timeouts and disconnects, aligned with the same run stages.
The workflow measurement contract helps define the success boundary. The prediction record makes the expected effect and disconfirming evidence explicit before a change.
The practical takeaway is to evaluate connection population, resource pressure and useful work together. Keep the reported observations visible, and make the limits of the record just as clear.