Rate Limit Test Service

A simple HTTP service to test rate-limiting implementations. Designed for developers, QA teams, and security engineers.

Description

This HTTP service returns status code `200` if the request is within the configured rate limits, and `429` if the request exceeds the limit. Status codes `404` and `50x` indicate incorrect usage or server errors.

The service accepts configurable parameters directly in the URL:

GET /ratelimit/{rate}/{burst}

`rate`: requests per second allowed.
`burst`: maximum burst size allowed.

Usage Instructions

Example request to allow 10 requests per second with a burst of 5 requests:

GET https://http429.com/ratelimit/10/5

Responses:

`200`: Request successful, within rate limits.
`429`: Too many requests, rate limit exceeded.
`404`: Invalid parameters or endpoint.
`50x`: Internal server errors.

curl example

Test the endpoint with `curl`:

curl -i https://http429.com/ratelimit/10/5

h2load example

Test the endpoint with `h2load` to simulate rate conditions:

h2load -D 10 -c 5 -m 1 https://http429.com/ratelimit/10/3
starting benchmark...
spawning thread #0: 5 total client(s). Timing-based test with 0s of warm-up time and 10s of main duration for measurements.
Warm-up started for thread #0.
progress: 20% of clients started
progress: 40% of clients started
progress: 60% of clients started
progress: 80% of clients started
progress: 100% of clients started
Warm-up phase is over for thread #0.
Main benchmark duration is started for thread #0.
TLS Protocol: TLSv1.3
Cipher: TLS_AES_128_GCM_SHA256
Server Temp Key: X25519 253 bits
Application protocol: h2
Main benchmark duration is over for thread #0. Stopping all clients.
Stopped all clients for thread #0

finished in 10.00s, 135.50 req/s, 24.65KB/s
requests: 1355 total, 1360 started, 1355 done, 100 succeeded, 1255 failed, 0 errored, 0 timeout
status codes: 100 2xx, 0 3xx, 1255 4xx, 0 5xx
traffic: 246.53KB (252450) total, 7.94KB (8130) headers (space savings 94.22%), 214.48KB (219625) data
					min         max         mean         sd        +/- sd
time for request:    11.27ms    337.83ms     36.40ms     76.96ms    92.69%
time for connect:    25.60ms     28.80ms     26.82ms      1.35ms    80.00%
time to 1st byte:    44.26ms    345.40ms    163.81ms    130.11ms    80.00%
req/s           :      23.40       29.49       27.10        2.59    80.00%

Requests: 1355, just 100 (10 rps * 10 seconds) succeeded.

Use Cases

Rate Limit Avoidance Testing

Test your proxy or scraper configurations to see if your methods can successfully avoid or handle rate limits.

Rate Limit Compliance Testing

Validate that your respectful client software correctly adapts to external services' rate limits, properly handling throttling.

API Gateway and Proxy Development

Ensure your gateway or proxy configurations accurately enforce your intended rate-limit policies.

Benchmarking and Reliability Testing

Evaluate your software’s retry logic, backoff algorithms, and error handling when facing real-world throttling conditions.

Security and Abuse Prevention

Simulate and validate the effectiveness of your rate-limit mechanisms against abuse, bots, and malicious traffic.

Legal

Privacy Policy

No data is collected or stored, however GDPR-compliant analytics by Plausible is used to track usage.

Terms of Service

There are no guarantees of uptime or availability. Use at your own risk. No liability is accepted for any loss or damage.

Human-readable stuff

The service is provided on the best effor basis on a small VPS. Consider running tests with relatively small number of requests to avoid hitting network/VM limits.

There is no reason to publish the source code, as it is just one simple config based on examples from resty.limit.req.