Nginx HTTP Server : Basic Nginx Configuration - A configuration for your profile

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.

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.