How QPS is measured
A query can be a database lookup, API call, search request or HTTP request. Before comparing QPS figures, check whether they count requests received, completed successfully or completed with any result.
Calculate average QPS by dividing the number of queries by the measurement period in seconds. If an API completes 600 requests in 10 seconds, its average throughput is 60 QPS. That average can hide short spikes, so monitoring often reports both an average and a peak measured in one-second windows.
High QPS doesn’t automatically mean good performance. Failed requests can raise the number, while slow responses can still produce poor results for users.
QPS vs concurrency and latency
QPS measures a rate. Concurrency counts how many requests are in progress, while latency measures how long each request takes.
| Metric | Measures | Example |
|---|---|---|
| QPS | Requests per second | 20 requests each second |
| Concurrency | Requests in progress | 10 open requests |
| Latency | Time per request | 500 milliseconds |
For a stable workload, average concurrency is approximately QPS multiplied by average response time. At 20 QPS and 0.5-second latency, you can expect about 10 requests in progress. This estimate requires stable averages and aligned measurement boundaries. During short bursts, instantaneous QPS and concurrency can diverge.
Why QPS matters with proxies
When you use a proxy, QPS can be measured between your client and the proxy or between the proxy and the target. Retries and proxy errors may make those figures different. One web page can also trigger many requests for HTML, scripts and images, so pages per second isn’t the same as QPS.
Websites, APIs, CDNs and firewalls often apply rate limiting by IP address, account or API key. Sending requests through more proxy IPs changes where traffic comes from, but it doesn’t grant permission to exceed a site’s limits. Excessive traffic may receive 429 Too Many Requests responses.
How to control QPS
- Check published limits. Follow API documentation, robots.txt and the site’s terms.
- Throttle the total rate. Apply limits across all workers and proxies, not just to each proxy separately.
- Cap concurrency. Use a queue so slower responses don’t create an uncontrolled number of open requests.
- Handle 429 responses. Honor
Retry-Afterwhen present and use exponential backoff before retrying. - Measure useful throughput. Track successful QPS alongside latency and error rates.
FAQ
What is a good QPS?
It depends on the system and its published limits. A good QPS is a sustainable rate that meets your workload without increasing latency or errors.
Is QPS the same as requests per second?
Often, yes. “QPS” is common for databases, search systems and APIs, while “requests per second” is common for web traffic. Always check what the metric counts.
Does using more proxies increase QPS?
Not by itself. More proxies can distribute requests across IP addresses, but your client, proxy gateway and target service still have capacity and rate limits.