This article covers key configurations for optimizing nginx web server performance, including gzip compression, proxy_buffer settings, and worker and keep-alive settings.
It emphasizes the importance of gzip compression and proxy_buffer buffering to reduce data transfer volume and minimize server load, as well as connection management through worker processes and keep-alive settings.
It suggests applying optimal settings tailored to your server environment after various tests and provides precautions for stable server operation.
Nginx is an open-source software frequently used as a web server or a reverse proxy server.
With proper configuration, it can efficiently deliver static content.
I'd like to document some of its key configurations.
Several Key Configurations Related to Performance
1. gzip Compression
When loading a website, numerous files such as JavaScript, images, HTML, and CSS are received from the web server.
Instead of delivering this content as is, utilizing gzip compression can significantly reduce the amount of data transmitted.
In other words, applying this results in:
- Reduced data volume, saving bandwidth.
- Server resource savings.
- Faster actual loading speed for users.
On the other hand, since the server needs to perform gzip compression before responding with the content, CPU usage might increase.
Testing is essential before applying it to a production environment. This includes determining which file types to compress, the compression level, and the minimum file size for compression.
Here are some gzip-related configurations.
gzip on; # Enables gzip compression.
gzip_vary on; # Adds Vary: Accept-Encoding header.
gzip_proxied any; # Compresses responses received from the backend if nginx is used as a proxy server. (Compression for proxied requests)
gzip_min_length 256; # Compresses files larger than 256 bytes.
gzip_comp_level 5; # Sets the compression level from 1 to 9. Higher levels increase CPU usage. 5 compresses approximately 50%.
gzip_types text/plain text/css text/xml application/json application/javascript;
// Sets the content types to be compressed.
* `gzip_vary` instructs the server to send compressed and uncompressed versions of the content depending on whether the client supports gzip. (Indicates that different versions of the content may be provided depending on the client's request header (Accept-Encoding)).
2. proxy_buffer Configuration
Nginx stores responses in a buffer before sending them to the client.
When a web server sends a response to a client, if the client is slow, the server has to wait to transmit data. (Network bottleneck)
This continuously uses server resources. To resolve this, a buffer is used to temporarily handle responses regardless of the client's processing speed. This provides the following advantages:
- Optimized server load
- Reduced network bottlenecks
location / {
proxy_pass server_url;
# Proxy buffer settings
proxy_buffering on; # Enables buffering.proxy_buffer_size 4k; # Sets the buffer size.(Mainlyfor headers).proxy_buffers8 4k; # Number and size of buffers for each connection(8 buffers of 4kb each).proxy_busy_buffers_size 8k; # Maximum buffer size available while sending a response to the client.}
※ Setting the buffer size too large can delay real-time data transmission like text streaming; therefore, testing is necessary. This is especially important with the recent rise of AI services; if text streaming isn't working, be sure to check this setting.
3. worker and http Configuration
Workers are processes that handle client requests, and you can configure how many to have per CPU core on the server.
HTTP typically involves request-connect-response-disconnect. To reduce the resources used for connections over multiple requests, you can keep the client connection alive. This is the keep-alive setting.
worker_processes auto; # Automatically sets based on the number of available CPU cores.
worker_connections 1024; # Number of connections each worker can handle simultaneously.
# Keep-alive settings
keepalive_timeout 65;
keepalive_requests 100;
server {
listen 80;
location / {
proxy_pass server url;
}
}
The reason these two are grouped together is as follows:
If your server has 4 cores, the theoretically possible number of connections is 1,024 * 4 = 4,096.
(This might not be accurate depending on resources and traffic conditions)
When 4,096 clients are simultaneously connected and occupying all keep-alives for 65 seconds,
If a 4,097th user tries to connect, they won't be able to, potentially causing response delays.
Therefore, assuming that server resources are stable (e.g., with auto-scaling), if response delays occur during events, these settings could indirectly contribute.
4. Others - location block
Some settings, such as proxy buffers, can be applied per request URL.
* Some settings like keep-alive are applied at the HTTP/Server level and cannot be set per block.
server { listen 80; server_name example.com;
# Handling the base path(/)location/{ proxy_pass server url; # Buffering settings
proxy_buffering on; proxy_buffers 8 16k; proxy_buffer_size 32k; proxy_busy_buffers_size 64k;}# Handling the /test path
location/test { proxy_pass server url2; # Disabling buffering
proxy_buffering off; # Disablesbuffering(immediate response transmission)}}
These settings can optimize web performance. After thorough testing with various test cases, optimize your server's performance!
* You can apply modified Nginx settings without server downtime, making it generally stable.