So far, we have built an NGINX configuration to make the best use of the available platform. This is just one part of the story where we have optimized NGINX request processing. We can also customize various client-side parameters to better utilize the available network, thus increasing the throughput.
In this chapter, we will cover the following topics:
- Configuring buffers
- Configuring timeouts
- Compression
- Controlling logs
- Setting up the server
Request buffers serve an important role in NGINX request handling. On receiving a request, NGINX writes it to these buffers. The data in these buffers is available as NGINX variables, such as $request_body. If the buffers are small in comparison to the request size, the data gets written to files on the disk and, thus, would involve I/O. NGINX provides various directives that can alter request buffers.
This directive sets the buffer size used for the request body. If the body exceeds the buffer size, either the complete body or a part of it gets written to a temporary file. This directive gets ignored if NGINX is configured to use files instead of the memory buffer. By default, the directive sets an 8k buffer for 32-bit systems and a 16k buffer for 64-bit systems. The directive is available under the http, server, and location sections of an NGINX configuration. Here's an example:
server{
client_body_buffer_size 8k;
}This directive sets the maximum request body size handled by NGINX. If the request is larger than the specified size, then NGINX sends back the HTTP 413(Request Entity too large) error. The directive is of importance if the server handles large file uploads.
By default, the directive sets 1m as the maximum limit. This directive is available under the http, server, and location sections of an NGINX configuration. Here's an example:
server{
client_max_body_size 2m;
}This directive disables NGINX buffers and stores the request body in a temporary file. The file contains data as plain text. The directive is available under the http, server, and location sections of an NGINX configuration. It can have one of the following three values:
off: The value will disable file writing.clean: The request body will be written to a file. The file will be removed after processing the request.on: The request body will be written to a file. The file will not be removed after processing the request.
By default, the directive is set to off. Here's an example:
http{
client_body_in_file_only clean;
}This directive instructs NGINX to store the complete request body in a single buffer. By default, the directive is set to off. If enabled, it optimizes I/O while reading the $request_body variable. The directive is available under the http, server, and location sections of an NGINX configuration. Here's an example:
server{
client_body_in_single_buffer on;
}This directive specifies the location to store temporary files for the request body. In addition to the location, the directive can also specify whether the files need a folder hierarchy up to three levels. The level is specified as the number of digits used to generate the folder.
By default, NGINX creates temporary files in the client_body_temp folder under the NGINX installation path. The directive is available under the http, server, and location sections of an NGINX configuration. Here's an example:
server{
client_body_temp_pathtemp_files 1 2;
}This directive will generate paths, such as temp_files/1/05/0000003051, under the NGINX prefix location.
This directive is similar to client_body_buffer_size. It allocates a buffer for request headers. If the request header does not fit into a specified buffer, the large_client_header_buffers directive is used to allocate a bigger buffer.
The default value of 1k is good enough for all intents and purposes. This directive is available under the http and server sections of an NGINX configuration:
http{
client_header_buffer_size 1m;
}This directive specifies the maximum number and size of buffers used for reading large client request headers. These buffers are allocated on demand only when the default buffers are insufficient. The buffers are released when the request is processed or the connection gets transitioned into the keep-alive state.
The default values of 4k and 8k buffers are good enough for all intents and purposes. The directive is available under the http and server sections of an NGINX configuration:
http{
large_client_header_buffers 4 8k;
}If the request URI exceeds the size of a single buffer, NGINX sends back the HTTP 414(Request URI Too Long) error to the client. Also, if any request header field exceeds the size of a single buffer, NGINX sends back the HTTP 400 (Bad Request) error to the client.