Key Configurations for Using nginx as a Web Server

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_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

※ 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.

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;

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.