Why Burst and nodelay options in Nginx? - Purpose & Use Cases

The Big Idea

What if your website could handle sudden crowds like a pro without making anyone wait?

The Scenario

Imagine you run a popular website that suddenly gets a flood of visitors all at once, like during a big sale or event.

You try to handle each visitor request one by one without any special settings.

The Problem

Without controls, your server gets overwhelmed, causing slow responses or even crashes.

Visitors get frustrated waiting, and some requests might be dropped or delayed unpredictably.

The Solution

The burst option lets your server temporarily handle extra requests beyond the usual limit, like a short buffer.

The nodelay option makes sure these extra requests are processed immediately without waiting in line.

Together, they smooth out sudden traffic spikes and keep your site responsive.

Before vs After

✗ Before

limit_req zone=one burst=0;

✓ After

limit_req zone=one burst=10 nodelay;

What It Enables

This lets your server gracefully handle sudden bursts of traffic, keeping users happy and your site stable.

Real Life Example

During a flash sale, many users try to buy at once. Using burst and nodelay, your site quickly accepts extra orders without making customers wait.

Key Takeaways

Manual rate limiting can block or delay users during traffic spikes.

Burst allows extra requests to be accepted temporarily.

Nodelay processes these extra requests immediately for better user experience.

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