Burst and nodelay options in Nginx - Commands & Configuration

Introduction

Sometimes many users try to access a website at the same time, causing slow responses or errors. The burst and nodelay options in nginx help control how many requests can wait and how fast they are processed to keep the site running smoothly.

When you want to limit how many users can send requests at once to avoid overloading your server.

When you want to allow a few extra requests to wait briefly during sudden traffic spikes.

When you want to decide if waiting requests should be delayed evenly or processed immediately.

When you want to protect your backend from too many requests arriving too quickly.

When you want to improve user experience by controlling request flow during busy times.

Config File - nginx.conf

nginx.conf

http {
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;

    server {
        listen 80;

        location / {
            limit_req zone=mylimit burst=10 nodelay;
            proxy_pass http://localhost:8080;
        }
    }
}

limit_req_zone defines a shared memory zone named 'mylimit' to track request rates per user IP, allowing 5 requests per second.

limit_req inside the location applies the rate limit using the 'mylimit' zone, allows a burst of 10 extra requests to queue, and uses nodelay to process queued requests immediately without delay.

This setup helps control traffic spikes by letting some extra requests pass quickly without slowing down users.

Commands

Check the nginx configuration file for syntax errors before applying changes.

Terminal

sudo nginx -t

Expected Output

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Reload nginx to apply the new configuration without stopping the server.

Terminal

sudo systemctl reload nginx

Expected Output

No output (command runs silently)

Send a request to the nginx server to verify it responds correctly under the new rate limiting rules.

Terminal

curl -s -w "%{http_code}\n" http://localhost/

Expected Output

200

Key Concept

If you remember nothing else from this pattern, remember: burst allows extra requests to queue temporarily, and nodelay makes those queued requests process immediately without waiting.

Common Mistakes

Setting burst too low or too high without testing traffic patterns.

Too low burst blocks users too quickly; too high burst defeats rate limiting purpose.

Choose a burst value that matches expected traffic spikes and test under load.

Using nodelay without understanding it causes queued requests to process immediately.

This can cause sudden bursts of traffic hitting backend all at once, possibly overloading it.

Use nodelay only if your backend can handle sudden bursts; otherwise omit it to delay queued requests.

Not testing nginx config syntax before reload.

Syntax errors cause nginx to fail reloading, leading to downtime.

Always run 'nginx -t' before reloading to ensure config is valid.

Summary

Define a limit_req_zone to track request rates per user IP.

Use limit_req with burst to allow extra queued requests during spikes.

Add nodelay to process queued requests immediately if desired.

Test nginx config syntax with 'nginx -t' before reloading.

Reload nginx to apply changes without downtime.

Practice

1. What does the burst option do in nginx rate limiting?

easy

A. Processes all requests without any limit

B. Immediately rejects extra requests beyond the limit

C. Allows extra requests to wait in a queue before being processed

D. Delays all requests by a fixed time

Solution

1. Step 1: Understand the purpose of burst

   The burst option in nginx allows extra requests that exceed the rate limit to be queued temporarily instead of being rejected immediately.

2. Step 2: Compare with other options

   Unlike rejecting or delaying all requests, burst specifically queues extra requests to handle traffic spikes smoothly.

3. Final Answer:

   Allows extra requests to wait in a queue before being processed -> Option C

4. Quick Check:

   Burst = queue extra requests [OK]

Hint: Burst queues extra requests to handle spikes smoothly [OK]

Common Mistakes:

• Thinking burst rejects extra requests immediately
• Confusing burst with fixed delay
• Assuming burst processes all requests without limit

2. Which is the correct syntax to enable burst with 10 requests and nodelay in nginx?

easy

A. limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s; limit_req zone=mylimit burst=10 nodelay;

B. limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s; limit_req zone=mylimit burst=10 delay;

C. limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s; limit_req zone=mylimit burst=10;

D. limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s; limit_req zone=mylimit nodelay burst=10;

Solution

1. Step 1: Identify correct order and keywords

   The correct syntax places burst=10 followed by nodelay without extra keywords like delay.

2. Step 2: Validate syntax correctness

   limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s; limit_req zone=mylimit burst=10 nodelay; correctly uses limit_req_zone and limit_req directives with proper parameters and order.

3. Final Answer:

   limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s; limit_req zone=mylimit burst=10 nodelay; -> Option A

4. Quick Check:

   Syntax with burst=10 and nodelay = limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s; limit_req zone=mylimit burst=10 nodelay; [OK]

Hint: Use burst=number before nodelay in limit_req [OK]

Common Mistakes:

• Using 'delay' instead of 'nodelay'
• Placing nodelay before burst
• Omitting limit_req_zone directive

3. Given this nginx config snippet:

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
limit_req zone=one burst=3 nodelay;

What happens if 5 requests arrive instantly from the same IP?

medium

A. All 5 requests are processed immediately

B. First 4 requests processed immediately, 5th rejected

C. First request processed immediately, next 4 delayed

D. Only 1 request processed, others rejected

Solution

1. Step 1: Understand rate and burst limits

   The rate is 1 request per second, burst allows 3 extra requests queued, and nodelay means queued requests run immediately.

2. Step 2: Analyze 5 instant requests

   The first request is within rate limit, next 3 fit in burst queue and run immediately due to nodelay, the 5th exceeds burst and is rejected.

3. Final Answer:

   First 4 requests processed immediately, 5th rejected -> Option B

4. Quick Check:

   Burst=3 + nodelay means 4 immediate, 5th rejected [OK]

Hint: Burst + nodelay = burst requests processed immediately [OK]

Common Mistakes:

• Assuming all 5 requests pass immediately
• Thinking requests after burst are delayed, not rejected
• Ignoring nodelay effect

4. You configured burst=5 but your nginx still rejects extra requests immediately. What is the likely cause?

medium

A. You forgot to add the nodelay option

B. The limit_req_zone directive is missing

C. The burst value must be less than 5

D. You need to restart nginx twice

Solution

1. Step 1: Check burst behavior without nodelay

   Without nodelay, burst requests are delayed, not processed immediately, but if delay is too long, clients may see rejections.

2. Step 2: Identify missing nodelay effect

   If extra requests are rejected immediately despite burst, likely nodelay is missing, causing strict rate enforcement.

3. Final Answer:

   You forgot to add the nodelay option -> Option A

4. Quick Check:

   Missing nodelay causes immediate rejection despite burst [OK]

Hint: Add nodelay to process burst requests immediately [OK]

Common Mistakes:

• Assuming burst alone allows immediate processing
• Thinking burst must be less than 5
• Believing multiple restarts fix config issues

5. You want to handle sudden spikes of up to 20 extra requests per second without delay, but reject any beyond that. Which nginx config snippet achieves this?

hard

A. limit_req_zone $binary_remote_addr zone=spike:10m rate=20r/s;
limit_req zone=spike burst=5 nodelay;

B. limit_req_zone $binary_remote_addr zone=spike:10m rate=25r/s;
limit_req zone=spike burst=0;

C. limit_req_zone $binary_remote_addr zone=spike:10m rate=5r/s;
limit_req zone=spike burst=0 nodelay;

D. limit_req_zone $binary_remote_addr zone=spike:10m rate=5r/s;
limit_req zone=spike burst=20 nodelay;

Solution

1. Step 1: Set base rate and burst for spikes

   The base rate is 5 requests per second, and burst=20 allows 20 extra requests queued.

2. Step 2: Use nodelay to process burst immediately

   Adding nodelay ensures the burst requests are processed right away without delay.

3. Step 3: Confirm rejection beyond burst

   Requests beyond burst=20 will be rejected, matching the requirement.

4. Final Answer:

   limit_req_zone $binary_remote_addr zone=spike:10m rate=5r/s; limit_req zone=spike burst=20 nodelay; -> Option D

5. Quick Check:

   Rate=5r/s + burst=20 + nodelay = limit_req_zone $binary_remote_addr zone=spike:10m rate=5r/s; limit_req zone=spike burst=20 nodelay; [OK]

Hint: Set burst high with nodelay to handle spikes immediately [OK]

Common Mistakes:

• Setting burst too low for spikes
• Omitting nodelay causing delays
• Setting rate too high ignoring burst