Throughput

Throughput is the data your connection actually delivers per second, in contrast to bandwidth, which is the theoretical ceiling. Real throughput is almost always lower than headline bandwidth because of protocol overhead, packet loss, congestion and — crucially — latency. On high-latency links, protocols like TCP spend time waiting for acknowledgements, so throughput drops even when plenty of bandwidth is free. Measuring it means transferring a real payload and timing it, not reading an advertised number.

When you route through a proxy or VPN, throughput depends on the slowest link in the chain and on the extra latency the hop introduces. For bulk work — downloading datasets, large scrapes — throughput is the number to watch; for chatty, request-heavy work, latency usually dominates. To get an honest figure, transfer a representative file through the connection and time it rather than trusting a speed-test headline. s4m proxies are metered pay-as-you-go, so understanding your real throughput also helps you predict data usage and cost before a large job.

If throughput disappoints, isolate the cause before blaming the proxy: run the same transfer without the hop, then on a different exit, then at a different time of day. Parallel streams can raise aggregate throughput on high-latency links where a single TCP flow underperforms. Because s4m proxies are metered, sizing a job by its data volume rather than its duration gives the most accurate cost estimate before you begin.