Gbps vs pps: when your link saturates before your app

Gbps and pps measure different ceilings

Gbps (gigabits per second) is a bandwidth metric: how much data crosses an interface or uplink in one second. Network quotes, ISP plans, and DDoS scrubbing capacity are often expressed in Gbps because volumetric stress is about moving bits on the wire.

pps (packets per second) is a packet-processing metric: how many discrete frames your NIC, router, firewall, or load balancer must classify, route, and (for stateful gear) track per second. Many devices hit a pps limit before they run out of Gbps, especially with small packets.

Your app might report low CPU and stable latency while users see timeouts. That pattern often means the path is full or dropping packets, not that the application tier ran out of capacity. For a broader primer on layers and dashboards, see Layer 4 vs Layer 7, RPS, Gbps & pps.

Why the link saturates before the app

Think of traffic as trucks on a highway. Gbps is how much cargo moves; pps is how many trucks pass the toll booth. A 1 Gbps link can be “full” with either a few large payloads or a flood of tiny ones—but firewalls and small VMs usually choke on truck count (pps) first.

Common situations where the network wins the race to failure:

• Small packets at high rate — SYN-heavy or UDP-style patterns can consume pps on state tables while Gbps counters still look modest.
• Uplink smaller than you think — A beefy origin behind a 100 Mbps VPS uplink saturates the pipe while nginx shows plenty of worker capacity.
• Shared or burstable hosting — Neighbor noise or provider caps show up as packet loss and retransmits before app metrics move.
• CDN or scrubbing in front — Edge absorbs or drops traffic; origin looks idle while clients fail at the edge.
• Asymmetric paths — Upload-heavy tests or reflection-style patterns can fill return paths that monitoring on the server never sees.

Layer 7 stress (HTTP RPS) can still trigger network limits when responses are large, TLS is heavy, or keep-alive behavior multiplies connections. The app is “slow” because bits cannot arrive or leave fast enough—not because your code path is the first to break.

Packet size links Gbps and pps

At a fixed Gbps, smaller packets mean higher pps. Rough intuition (ignoring overhead):

pps ≈ (Gbps × 10⁹) / (packet_size_bits)

Example: 1 Gbps of 64-byte frames implies vastly more packets per second than 1 Gbps of 1,400-byte frames. Two tests labeled “1 Gbps” can stress completely different hardware limits. That is why comparing stress results without noting packet size and method is misleading.

When you run authorized tests on infrastructure you own, record: target layer (L4/L7), claimed Gbps, observed pps (if your panel or snmp exposes it), and mean packet size. Otherwise you may optimize application code while the real ceiling is a 1 Gbps port or a firewall pps table.

How to tell which limit you hit

Symptoms that point to link or packet-processing saturation (not app CPU):

• Rising packet loss, retransmits, or RTT on the path; interface counters near 100% utilization.
• Firewall or router CPU pegged while application servers stay calm.
• Errors that look like timeouts or connection resets with few 5xx responses from the app itself.
• Gbps flat at the uplink cap while RPS or pps could still climb in theory.

Symptoms that point to application saturation first:

• CPU, memory, GC, or thread pool exhaustion on app hosts under moderate Gbps.
• Database connection pool waits, queue depth, or dependency timeouts with healthy interface stats.
• HTTP 5xx or rising p95/p99 latency while network utilization is well below the link cap.

During a controlled stress test, watch both sides: edge/network metrics and app metrics. If only the server dashboard is instrumented, you will misdiagnose link saturation as “the app is fine.”

What to do when the pipe fills first

1. Measure the real uplink and edge caps — Confirm committed bandwidth, burst policy, and provider DDoS/scrubbing tiers; compare to peak test volume in Gbps and estimated pps.
2. Upgrade or split the path — More uplink capacity, anycast, or moving static assets behind a CDN reduces bits and connection load on origin.
3. Tune stateful gear — Session timeouts, SYN cookies, connection limits, and hardware offload where appropriate (in staging first).
4. Align test design with production — Match packet sizes, TLS, and concurrency to real clients; a test that only measures large-payload Gbps will not predict small-packet pps failure.
5. Re-test after each change — The knee in the curve should move; document Gbps, pps, latency, and errors together.

Use Stressify.ST only on systems you are authorized to test. Coordinate with your host or security team so volumetric results are interpreted as capacity data—not as surprise incidents.

Designing stress tests that expose the right bottleneck

A useful program includes at least two scenarios: one that stresses application request rate (L7 / RPS) and one that stresses network volume or packet rate (L4 / Gbps and pps), within your plan limits and written scope.

• If production users mostly hit HTTPS APIs, start with L7 RPS and latency—but check whether responses are large enough to saturate egress.
• If you rely on UDP gaming, VoIP, or custom TCP services, L4-style metrics (Gbps, pps, connection churn) may predict failure earlier than HTTP RPS alone.
• When a test maxes Gbps but the app is idle, stop scaling RPS and investigate the path before profiling code.
• When Gbps is low but pps or connection tables explode, focus on edge hardening and packet behavior, not horizontal app scaling.

For a full workflow (goals, baselines, ramps), see How to stress test your server properly.

One-line cheat sheet

• Gbps full, app calm → link or volumetric path limit; check uplink, CDN, scrubbing.
• pps high, Gbps moderate → small packets or stateful gear; check firewall/NIC/router tables.
• Gbps low, app unhealthy → likely application or dependency limit; scale and profile the stack.