Concurrent connections

Concurrent connections is the count of WebSockets currently open between clients and a real-time service. The metric is a gauge, not a counter: it rises when a client connects and falls when one disconnects, with no accumulation over time.

Why it matters

Concurrent connections is the primary pricing dimension for most real-time providers, including Vask. It maps cleanly to capacity (each connection consumes a socket, some memory, and some kernel state on the edge node) and it scales with the size of the live audience, not with the publish rate. That makes it a more stable, more predictable billing axis than per-message or per-delivery counts.

It is also the dimension that determines a Vask tier. The published tiers (Free, Side, Indie, Business) are differentiated by their concurrent-connections cap, with broadcast and per-app counts as supporting limits. Sizing a tier comes down to predicting peak simultaneous users.

The cap is a soft signal in practice. Crossing it briefly during a viral moment triggers a grace period, not an immediate cutoff. Caps exist to protect customers from surprise overage, not to fail in real time.

How it works

A connection appears on the gauge when a client completes the WebSocket handshake and the service accepts it. It disappears when either side closes the socket. There is no in-between accounting; either the socket is open and counted, or it is not.

Pricing models typically sample this gauge:

  • Peak sampling. The highest measured concurrent count during the billing window. Punishes viral spikes.
  • 95th percentile. Drops the top 5% of samples. Forgiving of brief spikes; sensitive to sustained load.
  • Average. Total connection-seconds divided by billing seconds. Smooth, but slow to react to growth.

Vask uses peak with a grace window for the headline tier limit. This rewards steady operations and gives a planning runway when a feature lands well.

A few wire-level details. One client typically opens one connection, regardless of how many channels it subscribes to. Channel subscriptions are multiplexed inside the single WebSocket via the Pusher protocol. A user with 50 open channel subscriptions still counts as 1 concurrent connection.

Related terms

  • WebSocket is the connection that gets counted.
  • Fan-out and concurrent connections move together: each new connection adds one to the maximum possible fan-out factor on every channel it subscribes to.
  • Broadcast is the work unit that the connection count does NOT include.

See also

What are concurrent connections?
Concurrent connections is the number of WebSockets currently open between clients and the real-time service at a given moment. The metric is a gauge: it goes up when a client connects, down when a client disconnects.
How is the concurrent-connections count measured?
Most services sample the open-connection gauge at fixed intervals (often once per minute) and bill on the peak, the 95th percentile, or the average over the billing period. The exact sampling shape is provider-specific and worth reading before sizing a tier.
Is one user one connection?
Roughly. One browser tab usually opens one WebSocket and counts as one connection. Multiple tabs from the same user count as multiple connections. Server-to-server publishers do not count as subscriber connections; they use the publish API.