Following this long list of directives from
the base modules, we can begin to envision a first configuration adapted
to your profile in terms of targeted traffic and, more importantly, to
your hardware. In this section, we will first take a closer look at the
default configuration file to understand the implications of each
setting.
Understanding the default configuration
There is a reason why Nginx stands apart from other
web servers it's extremely lightweight, optimized, and to put it simply,
fast. As such, the default configuration is efficient, and in many
cases, you will not need to apply radical changes to the initial setup.
We will study the default configuration by opening up the main configuration file nginx.conf,
although you will find this file to be almost empty. The reason lies in
the fact that when a directive does not appear in the configuration
file, the default value is employed. We will thus consider the default
values here as well as the directives found in the original setup.
user root root;
worker_processes 1;
worker_priority 0;
error_log logs/error.log error;
log_not_found on;
events {
accept_mutex on;
accept_mutex_delay 500ms;
multi_accept off;
worker_connections 1024;
}
While this configuration may work out of the box, there are some issues you need to address right away.
Necessary adjustments
We will review some of the configuration directives that need immediate changing and the possible values you may set:
user root root;
This directive specifies that the worker
processes will be started as root. It is dangerous for security as it
grants full permissions over the filesystem. You need to create a new
user account on your system and make use of it here. The User and group management section
for more information on creating users and groups. Recommended value
(granted that you created an nginx user account and group on the system beforehand): user nginx nginx;
worker_processes 1;
With this setting, only one worker process
will be started, which implies that all requests will be processed by a
unique execution flow (the current version of Nginx is not
multi-threaded, by choice). This also implies that the execution is
delegated to only one core of your CPU. It is highly recommended to
increase this value; you should have at least one process per CPU core.
Recommended value (granted your server is powered by a quad-core CPU):worker_processes 4;
worker_priority 0;
By default, the worker processes are started
with a regular priority. If your system performs other tasks
simultaneously, you might want to grant a higher priority to the Nginx
worker processes. In this case, you should decrease the value the
smaller the value, the higher the priority. Values range from -20 (highest priority) to 19
(lowest priority). There is no recommended value here as it totally
depends on your situation. However, you should not set it under -5 as it is the default priority for kernel processes.
log_not_found on;
This directive specifies whether Nginx should log 404 errors
or not. While these errors may, of course, provide useful information
about missing resources, most of them are generated by web browsers
trying to reach the favicon (the conventional /favicon.ico of a website) or robots trying to access the indexing instructions (robots.txt). It is recommended that you disable log_not_found
in the case of conventional files that may clutter your log files.
However, do not disable this at the server level. Note that this
directive is part of the HTTP Core module.
worker_connections 1024;
This setting, combined with the amount of
worker processes, allows you to define the total quantity of connections
accepted by the server simultaneously. If you enable four worker
processes, each accepting 1,024 connections, your server will treat a
total of 4,096 simultaneous connections. You need to adjust this setting
to match your hardware: the more RAM
and CPU power your server relies on, the more connections you can
accept concurrently.
Adapting to your hardware
We will now establish three different setups a
standard one to be used by a regular website with decent hardware, a
low-traffic setup intended to optimize performance on modest hardware,
and finally an adequate setup for production servers in high-traffic
situations.
It's always difficult to classify computer power.
Firstly, because each situation has its own resources. If you work in a
large company, talking about a powerful computer
will not have the same meaning as in the case of standalone website
administrators who need to resort to third-party web hosting providers.
Secondly, because computers get more powerful every year: faster CPUs,
cheaper RAM, and the rise of new technologies (SSDs). Consequently, the
specifications given below are here for reference and need to be
adjusted to your own situation and to your era. The recommended values
for the directives are directly based on the specifications one worker
process per CPU core, maximum connections depending on the RAM, and so
on.
Low-traffic setup
|
Standard setup
|
High-traffic setup
|
---|
CPU: Dual-core
RAM: 2 GB
Requests: ~ 1/s
|
CPU: Quad-core
RAM: 4 GB
Requests: ~ 50/s
|
CPU: 8-core
RAM: 12 GB
Requests: ~1000/s
|
Recommended values
|
worker_processes 2;
worker_rlimit_nofile 1024;
worker_priority -5;
worker_cpu_affinity 01 10;
events {
multi_accept on;
work er_connections 128;
}
|
worker_processes 4;
worker_rlimit_nofile 8192;
worker_priority 0;
worker_cpu_affinity 0001 0010 0100 1000;
events {
multi_accept off;
work er_connections 1024;
}
|
worker_processes 8;
worker_priority 0;events {
multi_accept off;
work er_connections 8192;
}
|
There are two adjustments that have a critical
effect on the performance, namely, the amount of worker processes and
the connection limit. The first one, if set improperly, may clutter
particular cores of your CPU and leave other ones unused or underused.
Make sure the worker_processes match the quantity of cores in your CPU.
The second one, if set too low, could result
in connections being refused; if set too high, could overflow the RAM
and cause a system-wide crash. Unfortunately, there is no simple
equation to calculate the value of the worker_connections directive; you will need to base it on expected traffic estimations.