Performance bottleneck identification in Nginx - Commands & Configuration

Introduction

When a website or app feels slow, it often means something is blocking fast responses. Nginx can help find these slow spots by showing detailed logs and stats. This helps fix the problem and make the site faster.

When your website loads slowly and you want to find what part is causing delays

When you want to check if Nginx is handling requests efficiently or if it is overloaded

When you want to see detailed timing of requests to find slow backend services

When you want to monitor how many requests are active and how long they take

When you want to log errors or slow requests to improve your server setup

Config File - nginx.conf

nginx.conf

worker_processes auto;
events {
    worker_connections 1024;
}
http {
    log_format timed_combined '$remote_addr - $remote_user [$time_local] "$request" '
                              '$status $body_bytes_sent "$http_referer" '
                              '"$http_user_agent" $request_time $upstream_response_time';

    access_log /var/log/nginx/access.log timed_combined;

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://localhost:8080;
            proxy_connect_timeout 5s;
            proxy_read_timeout 10s;
        }
    }
}

worker_processes: Sets number of worker processes for handling requests.

log_format timed_combined: Custom log format that adds request_time and upstream_response_time to measure how long requests take.

access_log: Enables logging with the custom format to track request timings.

server block: Defines a simple proxy setup to forward requests to a backend server, with timeouts to avoid hanging.

Commands

Check if the Nginx configuration file is valid 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)

View the last 10 lines of the access log to see recent request timings and status codes.

Terminal

tail -n 10 /var/log/nginx/access.log

Expected Output

192.168.1.10 - - [27/Apr/2024:14:22:10 +0000] "GET /index.html HTTP/1.1" 200 1024 "-" "Mozilla/5.0" 0.123 0.120

192.168.1.11 - - [27/Apr/2024:14:22:11 +0000] "GET /api/data HTTP/1.1" 504 0 "-" "curl/7.68.0" 10.001 -

192.168.1.12 - - [27/Apr/2024:14:22:12 +0000] "POST /submit HTTP/1.1" 200 512 "-" "Mozilla/5.0" 0.456 0.450

→

-n 10 - Show last 10 lines of the log

Check Nginx version and compile options to ensure modules for performance monitoring are enabled.

Terminal

sudo nginx -V

Expected Output

nginx version: nginx/1.24.0

built by gcc 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)

configure arguments: --with-http_ssl_module --with-http_v2_module --with-stream --with-http_stub_status_module

Key Concept

If you remember nothing else from this pattern, remember: detailed request timing logs help pinpoint exactly where delays happen in Nginx.

Common Mistakes

Not enabling detailed timing in the log format

Without request_time and upstream_response_time, you cannot see how long requests or backend calls take, missing the bottleneck.

Add $request_time and $upstream_response_time variables to the log_format to capture timing.

Reloading Nginx without testing configuration first

If the config has errors, Nginx will fail to reload and cause downtime.

Always run 'nginx -t' to test config before reloading.

Ignoring proxy timeouts in server config

Without timeouts, slow backend responses can hang requests and block Nginx workers.

Set proxy_connect_timeout and proxy_read_timeout to reasonable values.

Summary

Configure Nginx to log detailed request and upstream response times.

Test and reload Nginx configuration safely to apply changes.

Use access logs to identify slow requests and backend delays.

Check Nginx version and modules to ensure monitoring features are available.

Practice

1. What is the primary purpose of enabling the stub_status module in nginx?

easy

A. To monitor active connections and request statistics

B. To enable SSL encryption for secure connections

C. To cache static files for faster delivery

D. To compress HTTP responses automatically

Solution

1. Step 1: Understand the stub_status module

   The stub_status module provides a simple way to get real-time statistics about nginx such as active connections and request counts.

2. Step 2: Identify its monitoring role

   It does not handle SSL, caching, or compression but focuses on performance metrics.

3. Final Answer:

   To monitor active connections and request statistics -> Option A

4. Quick Check:

   stub_status = monitor connections and requests [OK]

Hint: stub_status shows live connection and request stats [OK]

Common Mistakes:

• Confusing stub_status with SSL or caching modules
• Thinking it compresses responses
• Assuming it improves performance directly

2. Which of the following nginx configuration snippets correctly enables the stub_status page at /nginx_status?

easy

A. location /nginx_status { stub_status on; allow 127.0.0.1; deny all; }

B. location /nginx_status { stub_status; allow 127.0.0.1; deny all; }

C. location /nginx_status { stub_status on; allow all; }

D. location /nginx_status { status_stub on; allow 127.0.0.1; deny all; }

Solution

1. Step 1: Recall correct stub_status syntax

   The directive to enable stub_status is simply stub_status; without 'on'.

2. Step 2: Check access control correctness

   Allowing 127.0.0.1 and denying others is correct for security.

3. Final Answer:

   location /nginx_status { stub_status; allow 127.0.0.1; deny all; } -> Option B

4. Quick Check:

   stub_status directive has no 'on' [OK]

Hint: stub_status directive has no 'on' keyword [OK]

Common Mistakes:

• Adding 'on' after stub_status
• Using wrong directive name like status_stub
• Allowing all IPs without restriction

3. Given this nginx log excerpt showing many slow requests, which metric indicates a potential bottleneck?

medium

A. High number of 200 status codes

B. Low bytes_sent values

C. Frequent GET requests

D. High request_time values in access logs

Solution

1. Step 1: Understand request_time meaning

   The request_time shows how long nginx took to process a request; high values mean slow responses.

2. Step 2: Analyze other metrics

   Low bytes_sent or many 200 codes do not indicate slowness; frequent GETs are normal traffic.

3. Final Answer:

   High request_time values in access logs -> Option D

4. Quick Check:

   High request_time = slow requests [OK]

Hint: Look for high request_time to spot slow requests [OK]

Common Mistakes:

• Confusing status codes with performance
• Assuming bytes_sent relates to speed
• Ignoring request_time metric

4. You added the stub_status location but get a 404 error when accessing /nginx_status. What is the most likely cause?

medium

A. The location block syntax is incorrect with extra semicolons

B. The server block is missing the listen directive

C. The stub_status module is not compiled or enabled in nginx

D. The allow directive is missing

Solution

1. Step 1: Check module availability

   If stub_status is not compiled into nginx, the location will not work and return 404.

2. Step 2: Verify other config parts

   Incorrect syntax or missing listen usually cause config errors, not 404. Missing allow causes access denied, not 404.

3. Final Answer:

   The stub_status module is not compiled or enabled in nginx -> Option C

4. Quick Check:

   Missing stub_status module = 404 error [OK]

Hint: 404 on stub_status means module missing or disabled [OK]

Common Mistakes:

• Assuming syntax errors cause 404
• Confusing 404 with access denied errors
• Ignoring module compilation status

5. You want to identify if nginx worker processes are a bottleneck under high load. Which combined approach helps you best diagnose this?

hard

A. Check stub_status active connections and use top to monitor worker CPU usage

B. Only check nginx error logs for worker crashes

C. Increase worker_processes blindly without monitoring

D. Disable access logs to reduce disk usage

Solution

1. Step 1: Use stub_status for connection metrics

   stub_status shows active connections and requests, indicating load on workers.

2. Step 2: Monitor worker CPU usage with system tools

   Using top or similar tools shows if workers are maxing CPU, a sign of bottleneck.

3. Step 3: Combine metrics for diagnosis

   Both metrics together reveal if workers are overloaded or if other issues exist.

4. Final Answer:

   Check stub_status active connections and use top to monitor worker CPU usage -> Option A

5. Quick Check:

   Combine stub_status + CPU monitoring = diagnose bottleneck [OK]

Hint: Combine stub_status and CPU tools to find worker bottlenecks [OK]

Common Mistakes:

• Ignoring CPU usage of workers
• Changing config without data
• Relying only on logs or disabling logs