{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Safe/node {{ resultsReady ? formatSockets(computation.values.safe_connections_per_node) : '—' }} Bottleneck {{ resultsReady ? bottleneckLabel : '—' }} Target {{ resultsReady ? formatSockets(computation.values.target_connections) : '—' }}
sockets
Observed or forecasted open sockets before planning reserve.
nodes
Used only to compare today’s pool with the recommended plan.
sockets/node
A load-test or production ceiling, not a theoretical runtime maximum.
KB/socket
Measure the incremental resident memory from a representative staged load.
GB/node
The model uses binary GB-to-KB conversion for this capacity budget.
msg/socket/min
Use fanout traffic; a separate idle-only run should not replace peak push sizing.
bytes/msg
Use compressed bytes only when compression is consistently represented.
Mbps/node
Use a sustained measured ceiling rather than theoretical line rate.
%
Applied to peak sockets before the serving-node count is rounded up.
reserve nodes
Use 1 for N+1 or a larger whole-node failure domain when justified.
%
100% is neutral; use a lower measured operating ceiling for conservative planning.
%
100% is neutral; use a lower sustainable network ceiling when measured.
FDs/node
0 disables this optional ceiling. Positive values must exceed 1,024.
%
0% is neutral; use a measured blended overhead rather than assuming a fixed WebSocket frame size.
Presentation only; calculations retain full precision.
{{ row.label }} {{ row.display }}
Calculation method:
The minimum active per-node ceiling drives the serving set; N+ reserve is added afterward.
{{ formulaEquation }}
{{ row.label }}
{{ row.display }}
{{ row.detail }}

The chart renderer is unavailable. The same constraint values remain available in the capacity ledger.

CategoryMeasureValueOperator noteCopy
{{ row.category }} {{ row.label }} {{ row.display }} {{ row.detail }}
Load Balancer Pool Capacity Calculator Estimate weighted load balancer pool capacity from measured backend RPS and routing weights, with bottleneck and N+ failure-reserve checks.
Network Throughput Calculator Estimate useful network throughput and transfer time from link capacity and RTT with TCP window, loss and packet-rate bottleneck checks.
Bandwidth Delay Product Calculator Calculate bandwidth-delay product and per-stream TCP window targets from path rate and RTT, then compare current buffers and stream counts.
Load Balancer Failover Time Calculator Estimate user-visible load balancer failover time across health checks, routing changes, DNS cache exposure, and an RTO target.

A WebSocket node can run out of one resource while the others still look comfortable. Open connections consume runtime state and file descriptors. Fanout traffic consumes egress. Load balancers, proxies, and the application impose their own tested limits. Fleet capacity is therefore set by the smallest credible per-node ceiling, not by the largest headline number.

Long-lived connections also change failure planning. A pool that handles the forecast under normal conditions may fall short as soon as one node is drained, restarted, or lost. An N+1 plan reserves one whole node beyond the serving set; larger failure domains may justify N+2 or more.

ConstraintMeasurement that belongs in the model
Tested runtimeA sustained staged or production ceiling with the same application path and connection behavior.
MemoryIncremental resident memory per representative connection and the RAM budget left for connection state.
File descriptorsThe effective process limit after reserving descriptors for logs, listeners, upstreams, and runtime work.
EgressFanout messages per connection, average transmitted payload, protocol overhead, and sustained usable throughput.

An idle-socket test is not a substitute for a push test. Compression, heartbeat traffic, payload distribution, TLS termination, backpressure, reconnect storms, garbage collection, and load-balancer skew can all shift the limiting resource. Use measurements from the same topology and traffic shape that the production plan is meant to support.

How to Use This Tool:

Estimate concurrency first, then add message traffic, memory, CPU, and failover headroom.

  1. Enter the forecast Peak concurrent sockets and the size of the current WebSocket pool.
  2. Add a measured Tested connection cap per node, incremental memory per connection, and the RAM budget available for connection state.
  3. Describe outbound fanout with messages per connection per minute and average transmitted bytes, then enter a sustained node egress ceiling.
  4. Set planning reserve, memory and network utilization ceilings, and the whole-node loss reserve required by the availability plan.
  5. Enter the effective file-descriptor limit when it is known, or leave it at zero to exclude that constraint. A positive limit must exceed the reserved 1,024 descriptors.
  6. Read the active bottleneck and recommended pool together, then rerun a representative load test near the planned per-node load.

Interpreting Results:

Safe sockets per node is the lowest active ceiling after utilization settings and fixed reserves. Recommended pool adds the declared node-loss reserve after rounding up the serving set. Negative current headroom means the remaining nodes after that failure reserve cannot carry the reserved connection target.

The bottleneck label describes the numbers entered, not an independently observed production limit. If the result says memory is binding but the memory-per-connection value came from idle sockets, repeat the measurement with authentication state, subscriptions, buffers, compression, and fanout active.

Technical Details:

Capacity is computed in two stages. The first stage turns each measured resource into a whole-socket ceiling. The second stage divides reserved demand by the smallest ceiling, rounds up the serving nodes, and then adds whole reserve nodes.

Formula Core

Forecast demand is increased before node rounding so planning reserve cannot disappear inside a fractional node.

Ctarget = Cpeak (1+r100)

Memory uses binary gigabytes. Egress uses decimal megabits per second. Each connection's outbound bit rate includes the optional overhead percentage.

Cmemory = ⌊RAMGB×10242×umconnection⌋
Cegress = ⌊EMbps×106×nB×8×M×(1+o)60⌋

u and n are memory and network utilization fractions, B is average payload bytes, M is messages per connection per minute, and o is the protocol-overhead fraction. File-descriptor capacity is the configured limit minus 1,024; zero disables that constraint.

Rule Core

The active density is the minimum of tested, memory, egress, and optional descriptor ceilings. Node counts then use the following rule.

Nrecommended = ⌈Ctargetmin(Ctested,Cmemory,Cegress,Cfd)⌉ +Nloss

The descriptor term is omitted when its input is zero. Current failover capacity subtracts the declared reserve nodes from the current pool before multiplying by safe density. Planned per-node utilization assumes even distribution across the minimum serving set, so real imbalance remains outside the model.

Capacity Assumptions:

  • All nodes are treated as equivalent and connections are assumed to distribute evenly.
  • Outbound traffic is modeled as an average sustained rate, not a burst percentile or bidirectional peak.
  • Memory covers the entered incremental connection state; application baseline, caches, runtime overhead, and fragmentation require room in the node RAM budget.
  • The calculation does not model CPU, accept rate, TLS handshakes, reconnect storms, upstream dependencies, proxy limits, or regional failure.

Worked Examples:

Tested cap controls the pool

A forecast of 75,000 sockets with 25% reserve produces a 93,750-socket target. If the tested cap is 30,000 sockets per node and the memory and egress ceilings are higher, four serving nodes are required. Adding N+1 produces a five-node recommendation; a current three-node pool is short by two nodes under that failure-ready plan.

Descriptors become the bottleneck

A 20,000 descriptor limit leaves 18,976 connection descriptors after the fixed 1,024 reserve. With a 100,000-socket target and higher tested, memory, and bandwidth ceilings, descriptor capacity requires six serving nodes.

References: