Proxy Workload Sizing: GB, Mbps, Rate and Concurrency

Choose a proxy limit from the work you must finish, not from a label such as “bandwidth.” A monthly allowance (GB), a transfer-rate ceiling (Mbps), simultaneous in-flight attempts, and a release rate constrain different things. Write down all four before comparing a plan.

This guide is for an authorized data workflow that already has a defined target, validator, and deadline. It uses transparent hypothetical figures, not an IPHTML measurement, plan term, capacity claim, or recommendation. A permitted API, licensed feed, exported report, or manual check may remove the need for a proxy entirely.

1. Name the four limits before doing any math

Read the actual contract and dashboard definitions: a “connection” can be scoped differently from an application job, and a supplier may meter bytes differently from your client. A public provider FAQ illustrates that providers can separately describe per-GB products, port-linked concurrency, and Mbps tiers; it is only a vocabulary example, not evidence about IPHTML or any other supplier’s terms.

2. Start with valid jobs, then count attempts

A valid job is a business result that passes the predeclared validator and deadline. An attempt is one top-level request or job execution. A retry can add an attempt without adding a valid job; a response that fails validation is not silently counted as work completed.

For a hypothetical eight-hour window, suppose 48,000 distinct planned jobs need validation: 36,000 light checks and 12,000 detail checks. In this synthetic example, one job is one HTTP request per attempt, with no redirects, subrequests, or parser work inside the attempt duration. Each light attempt transfers 8 KiB up and 220 KiB down; each detail attempt transfers 12 KiB up and 1.8 MiB down. These are planning inputs only. A browser job needs a request-level ledger and rate controls because it can fan out. Headers, TLS framing, and supplier-specific metering can make an invoice differ.

light attempts:  36,000 × (8 + 220) KiB       = 8,208,000 KiB
detail attempts: 12,000 × (12 + 1.8 × 1,024) KiB = 22,262,400 KiB
first-attempt transfer = 30,470,400 KiB × 1,024 bytes/KiB
                       = 31,201,689,600 bytes
                       = 31.2016896 decimal GB

If 10% of first attempts in each workload class receive one eligible retry of the same byte size:
expected attempts = 48,000 × (1 + 0.10) = 52,800
expected transfer  = 31.2016896 × 1.10 = 34.32185856 decimal GB

The 10% and same-byte retry are assumptions, not forecasts. They apply once to each first-attempt class; do not add them again to a monthly total that already contains retried bytes. A retry policy must still honor authorization, Retry-After, time limits, and shared budgets. See the retry-budget guide for that stop decision.

3. Convert the same workload into an honest quota check

curl can record body bytes through size_upload and size_download; its manual says these exclude headers. Pair those fields with a transfer ID, response validation, and your supplier’s meter. They are useful client evidence, not proof of billed bytes or proxy performance.

4. Size rate and concurrency without treating an average as a ceiling

The scheduled first-attempt rate is 48,000 ÷ 28,800 = 1.6667 jobs/s. With the assumed retries, the expected attempt rate is 52,800 ÷ 28,800 = 1.8333 attempts/s. AWS documents the general relationship mean concurrency = average RPS × mean duration for Lambda. We use it only as a queueing analogy for a stable workload with the same attempt boundary: if measured mean duration from admission to finish were 1.2 seconds, excluding pre-admission queueing and any backoff that does not occupy the slot, mean in-flight attempts would be about 1.8333 × 1.2 = 2.2. It is a finite-window planning approximation, not a deadline guarantee.

Mean concurrency is not a hard cap. The illustrative hard cap of 8 in-flight attempts is a separately chosen scheduler setting; it is neither derived by rounding 2.2 nor a recommendation. Nor is p95 duration × mean RPS a “p95 concurrency”: percentiles cannot be multiplied that way without the joint arrival-and-duration data. Log a time series of actual active attempts and check its maximum or a declared percentile against the cap.

Assume, only for this screen, that a hypothetical 10 Mbps term is one shared aggregate ceiling for both directions and uses the same body-byte boundary. The expected transfer over eight hours is 34.32185856 GB × 1,000,000,000 bytes/GB × 8 bits/byte ÷ 28,800 s ÷ 1,000,000 = 9.5338 Mbps on average. That ceiling has a theoretical eight-hour payload of 10,000,000 bits/s × 28,800 s ÷ 8 = 36 decimal GB; it leaves only 1.6781 GB before framing, bursts, non-job traffic, or meter difference. If the actual term caps upload and download separately, calculate each direction separately. This is a feasibility screen, not a promise that 10 Mbps will deliver this workflow or that body bytes equal on-wire utilization.

5. Use a bounded launch policy

1. Freeze the authorized job list, deadline, byte boundary, validator, and which redirects/subrequests count.
2. Set an application release rate at or below every documented target, API, account, and supplier rule. A proxy setting never grants permission to bypass a rate limit.
3. Set a separate hard in-flight cap, and reserve capacity for cleanup or validation if those steps share workers.
4. Run a small representative, permitted sample. Record valid jobs, attempts, bytes, duration, active-attempt time series, stop reasons, and any supplier-meter reconciliation.
5. Hold expansion if a critical cell is untested, invoice terms are unknown, the deadline is missed, or rate permission is unclear.

Choose a representative workload first with the trial sampling plan. If the question is whether exits meet a context requirement at a bounded load, use the usable-capacity worksheet. For provider quotes and invoice terms, use the separate billing comparison; it should not inherit synthetic numbers from this page. Diagnose a slow transfer with the latency breakdown, not by raising concurrency.

6. Copy this operational worksheet

Download the bilingual workload-sizing CSV. It contains the hypothetical values above and blank evidence fields. Replace every sample input before use; it makes no request, chooses no plan, and cannot verify a limit.

Sources checked October 24, 2026: AWS’s concurrency documentation supports the mean-rate-times-mean-duration analogy only; curl’s manual defines its write-out byte fields; MDN’s 429 reference documents rate limiting and possible Retry-After. A public provider FAQ was used only to show that plans may label GB, Mbps, and concurrency separately. No IPHTML plan, price, capacity, trial, or performance test was inspected or claimed.