Worker Processes and Worker Connections

The first two variables we need to tune are the worker processes and worker connections. Before we jump into each setting, we need to understand what each of these directives control. The worker_processes directive is the sturdy spine of life for Nginx. This directive is responsible for letting our virtual server know how many workers to spawn once it has become bound to the proper IP and port(s). It is common practice to run 1 worker process per core. Anything above this won’t hurt your system, but it will leave idle processes usually just lying about.

To figure out what number you’ll need to set worker_processes to, simply take a look at the amount of cores you have on your setup. If you’re using the DigitalOcean 512MB setup, then it’ll probably be one core. If you end up fast resizing to a larger setup, then you’ll need to check your cores again and adjust this number accordingly. We can accomplish this by greping out the cpuinfo:

Let’s say this returns a value of 1. Then that is the amount of cores on our machine!

The command tells our worker processes how many people can simultaneously be served by Nginx. The default value is 768; however, considering that every browser usually opens up at least 2 connections/server, this number can half. This is why we need to adjust our worker connections to its full potential. We can check our core’s limitations by issuing a ulimit command:

On a smaller machine (512MB droplet) this number will probably read 1024, which is a good starting number.

Let’s update our config:

Remember, the amount of clients that can be served can be multiplied by the amount of cores. In this case, we can server 1024 clients/second. This is, however, even further mitigated by the directive.

Using Apache and Nginx Together

After going over the benefits and limitations of both Apache and Nginx, you may have a better idea of which server is more suited to your needs. However, many users find that it is possible to leverage each server’s strengths by using them together.

The conventional configuration for this partnership is to place Nginx in front of Apache as a reverse proxy. This will allow Nginx to to handle all requests from clients. This takes advantage of Nginx’s fast processing speed and ability to handle large numbers of connections concurrently.

For static content, which Nginx excels at, the files will be served quickly and directly to the client. For dynamic content, for instance PHP files, Nginx will proxy the request to Apache, which can then process the results and return the rendered page. Nginx can then pass the content back to the client.

This setup works well for many people because it allows Nginx to function as a sorting machine. It will handle all requests it can and pass on the ones that it has no native ability to serve. By cutting down on the requests the Apache server is asked to handle, we can alleviate some of the blocking that occurs when an Apache process or thread is occupied.

This configuration also allows you to scale out by adding additional backend servers as necessary. Nginx can be configured to pass to a pool of servers easily, increasing this configuration’s resilience to failure and performance.

Why Is Architecture Important?

The fundamental basis of any Unix application is the thread or process. (From the Linux OS perspective, threads and processes are mostly identical; the major difference is the degree to which they share memory.) A thread or process is a self‑contained set of instructions that the operating system can schedule to run on a CPU core. Most complex applications run multiple threads or processes in parallel for two reasons:

  • They can use more compute cores at the same time.
  • Threads and processes make it very easy to do operations in parallel (for example, to handle multiple connections at the same time).

Processes and threads consume resources. They each use memory and other OS resources, and they need to be swapped on and off the cores (an operation called a context switch). Most modern servers can handle hundreds of small, active threads or processes simultaneously, but performance degrades seriously once memory is exhausted or when high I/O load causes a large volume of context switches.

The common way to design network applications is to assign a thread or process to each connection. This architecture is simple and easy to implement, but it does not scale when the application needs to handle thousands of simultaneous connections.

Шаг 11 — Обслуживание статических файлов с помощью Nginx (необязательно)

Когда Nginx перенаправляет запросы доменов Apache через прокси-сервер, каждый запрос файла этого домена отправляется в Apache. Nginx обслуживает статические файлы, такие как изображения, JavaScript и таблицы стилей, быстрее Apache. Поэтому мы настроим файл виртуального хоста Nginx для прямого обслуживания статических файлов и перенаправления запросов PHP в Apache.

Откройте в своем редакторе файл :

Вам потребуется добавить два дополнительных блока в каждый блок server, а также изменить существующие разделы . Кроме того, вам нужно будет указать Nginx, где можно найти статические файлы для каждого сайта.

Если вы решили не использовать сертификаты SSL и TLS, измените свой файл, чтобы он выглядел следующим образом:


Если вы также хотите обеспечить доступность HTTPS, используйте следующую конфигурацию:


Директива указывает Nginx искать файлы в корне документа document root и выводить их напрямую. Если файл имеет расширение , запрос перенаправляется в Apache. Даже если файл отсутствует в document root, запрос перенаправляется в Apache, чтобы функции приложения (например, постоянные ссылки) работали без проблем.

Предупреждение. Директива очень важна, поскольку она не дает Nginx выводить содержимое файлов конфигурации Apache с важными данными, таких как и .

Сохраните файл и проведите тест конфигурации:

Если тест завершается успешно, перезагрузите Nginx:

Чтобы убедиться, что все работает, вы можете просмотреть файлы журнала Apache в каталоге и посмотреть запросы для файлов сайтов и . Используйте команду для просмотра последних нескольких строк файла и параметр для просмотра изменений файла:

Теперь откройте в браузере и посмотрите на результаты вывода журнала. Вы увидите ответ Apache:

Затем откройте страницы каждого сайта, и вы не увидите записи журнала Apache. Их обслуживает Nginx.

Завершив изучение файла журнала, нажмите чтобы остановить отслеживание.

При такой настройке Apache не сможет ограничивать доступ к статическим файлам. Контроль доступа к статическим файлам должен быть настроен в файле виртуального хоста Nginx, однако это не входит в содержание настоящего обучающего руководства.

Support, Compatibility, Ecosystem, and Documentation

A major point to consider is what the actual process of getting up and running will be given the landscape of available help and support among other software.


Because Apache has been popular for so long, support for the server is fairly ubiquitous. There is a large library of first- and third-party documentation available for the core server and for task-based scenarios involving hooking Apache up with other software.

Along with documentation, many tools and web projects include tools to bootstrap themselves within an Apache environment. This may be included in the projects themselves, or in the packages maintained by your distribution’s packaging team.

Apache, in general, will have more support from third-party projects simply because of its market share and the length of time it has been available. Administrators are also somewhat more likely to have experience working with Apache not only due to its prevalence, but also because many people start off in shared-hosting scenarios which almost exclusively rely on Apache due to the distributed management capabilities.


Nginx is experiencing increased support as more users adopt it for its performance profile, but it still has some catching up to do in some key areas.

In the past, it was difficult to find comprehensive English-language documentation regarding Nginx due to the fact that most of the early development and documentation were in Russian. As interest in the project grew, the documentation has been filled out and there are now plenty of administration resources on the Nginx site and through third parties.

In regards to third-party applications, support and documentation is becoming more readily available, and package maintainers are beginning, in some cases, to give choices between auto-configuring for Apache and Nginx. Even without support, configuring Nginx to work with alternative software is usually straight-forward so long as the project itself documents its requirements (permissions, headers, etc).

Resources # Resources


  • nginx + php-fpm + PHP APC + WordPress multisite (subdirectory) + WP Super Cache (Thanks bigsite)
  • Notes on removing ‘index.php’ from Permalinks (Can be done using Nginx Helper Plugin)

External Links

  • Nginx WordPress wiki page
  • Nginx Full Example
  • Nginx Full Example 2
  • LEMP guides on Linode’s Library
  • Various guides about Nginx on Linode’s Library
  • Lightning fast WordPress with Php-fpm and Nginx
  • Virtual Hosts Examples
  • List of 20+ WordPress-Nginx Tutorials for common situations
  • An introduction to Nginx configuration
  • A comprehensive blog series on hosting WordPress yourself using Nginx
  • WordPress Installation CentminMod
  • Nginx WordPress Installation Guide


Nginx logs every request that hits the VPS to a log file. If you use analytics to monitor this, you may want to turn this functionality off. Simply edit the directive:

Save and close the file, then run:


At the end of the day a properly configured server is one that is monitored and tweaked accordingly. None of the variables above are set in stone and will need to be adjusted to each unique case. Even further down the road, you may be looking to further your machine performance with research in load balancing and horizontal scaling. These are just a few of the many enhancements a good sysadmin can make to a server.


The Fancy Index module makes possible the generation of file listings, like the built-in autoindex module does, but adding a touch of style. This is possible because the module allows a certain degree of customization of the generated content:

  • Custom headers (either local or stored remotely).
  • Custom footers (either local or stored remotely).
  • Add you own CSS style rules.
  • Allow choosing to sort elements by name (default), modification time, or size; both ascending (default), or descending (new in 0.3.3).

This module is designed to work with NGINX, a high performance open source web server written by Igor Sysoev.

Nginx autoindex directives

Besides simply using autoindex on or off, there are also three other directives you can configure with this module. These include the following:

  • — This directive specifies whether Nginx should display the exact file sizes of the output in the directory index or simply round to the nearest KB, MB, or GB. This directive has two options: or .
  • — This directive specifies what format the Nginx index listing should be outputted to. This directive has four options: , , , or .
  • — This directive specifies whether the times for the directory listing should be outputted to local time or UTC. This directive has two options: or .

An example of a location directive using all four autoindex options could resemble the following.

Функции nginx

Nginx получил большую известность за счет своей высокой производительности, простой конфигурации, надежности и стабильности, а также достаточного набора функций.

nginx в качестве HTTP-сервера

  • Обработка статического контента, индексные файлы, листинг директорий, кэш дескрипторов открытых файлов;
  • Акселерированное проксирование с кэширование, распределение нагрузки и отказоустойчивостью;
  • Акселерированная поддержка FastCGI серверов с кэшированием, распределением нагрузки и отказоустойчивостью;
  • Модульная структура, поддержка различных фильтров (SSI, XSLT, GZIP, докачка, chunked ответы);
  • Поддержка SSL и расширения TLS SNI;
  • Ip-based или Name-based виртуальные сервера;
  • Работа с KeepAlive и pipelined соединениями;
  • Возможность конфигурирования любых тайм-аутов а так-же количества и размеров буферов, на уровне сервера Apache;
  • Выполнение различных действий в зависимости от адреса клиента;
  • Изменение URI с помощью регулярных выражений;
  • Специальные страницы ошибок для 4хх и 5хх;
  • Ограничение доступа на основе адреса клиента или по паролю;
  • Настройка форматов лог-файлов, ротация логов;
  • Ограничение скорости ответа клиенту;
  • Ограничение количества одновременных подключений и запросов;
  • Поддержка методов PUT, DELETE, MKCOL, COPY и MOVE;
  • Изменение настроек и обновление сервера без остановки работы;
  • Встроенный Perl

nginx в качестве почтового прокси-сервера

  • Форвардинг на IMAP/POP3 бакэнд, используя внешний HTTP сервер аутентификации;
  • Проверка SMTP пользователя на внешнем HTTP сервере аутентификации и форвардинг на внутренний SMTP сервер;
  • Поддержка следующих способов аутентификации:
  • Поддержка SSL;
  • Поддержка STARTTLS и STLS;

Inside the NGINX Worker Process

Each NGINX worker process is initialized with the NGINX configuration and is provided with a set of listen sockets by the master process.

The NGINX worker processes begin by waiting for events on the listen sockets ( and kernel socket sharding). Events are initiated by new incoming connections. These connections are assigned to a state machine – the HTTP state machine is the most commonly used, but NGINX also implements state machines for stream (raw TCP) traffic and for a number of mail protocols (SMTP, IMAP, and POP3).

The state machine is essentially the set of instructions that tell NGINX how to process a request. Most web servers that perform the same functions as NGINX use a similar state machine – the difference lies in the implementation.


The Inside NGINX infographic provides a high‑level overview of how NGINX functions, but behind this simple explanation is over ten years of innovation and optimization that enable NGINX to deliver the best possible performance on a wide range of hardware while maintaining the security and reliability that modern web applications require.

If you’d like to read more about the optimizations in NGINX, check out these great resources:

  • Installing and Tuning NGINX for Performance (webinar; slides at Speaker Deck)
  • Tuning NGINX for Performance
  • The Architecture of Open Source Applications – NGINX
  • Socket Sharding in NGINX Release 1.9.1 (using the socket option)


В nginx рабочие процессы обслуживают одновременно множество соединений, мультиплексируя их вызовами операционной системы select, epoll (Linux) и kqueue (FreeBSD). Рабочие процессы выполняют цикл обработки событий от дескрипторов (см. Событийно-ориентированное программирование). Полученные от клиента данные разбираются с помощью конечного автомата. Разобранный запрос последовательно обрабатывается цепочкой модулей, задаваемой конфигурацией. Ответ клиенту формируется в буферах, которые хранят данные либо в памяти, либо указывают на отрезок файла. Буфера объединяются в цепочки, определяющие последовательность, в которой данные будут переданы клиенту. Если операционная система поддерживает эффективные операции ввода-вывода, такие, как writev и sendfile, то nginx применяет их по возможности.

Алгоритм работы HTTP-сервера выглядит следующим образом:

  1. получить очередной дескриптор из kevent(2);
  2. прочитать данные из файла и записать в socket, используя либо write(2)/read(2), например, так:
      cnt = read
      ) == cnt
   byte_count += count;
либо используя системный вызов sendfile(2), выполняющий те же действия, что приведённый выше код, но в пространстве ядра;
  1. перейти к шагу 1.

Конфигурация HTTP-сервера nginx разделяется на виртуальные серверы (директива «server»). Виртуальные серверы разделяются на location’ы («location»). Для виртуального сервера возможно задать адреса и порты, на которых будут приниматься соединения, а также имена, которые могут включать «*» для обозначения произвольной последовательности в первой и последней части, либо задаваться регулярным выражением.

location’ы могут задаваться точным URI, частью URI либо регулярным выражением. location’ы могут быть сконфигурированы для обслуживания запросов из статического файла, проксирования на fastcgi/memcached сервер.

Для эффективного управления памятью nginx использует пулы. Пул — это последовательность предварительно выделенных блоков динамической памяти. Длина блока варьируется от 1 до 16 килобайт. Изначально под пул выделяется только один блок. Блок разделяется на занятую область и незанятую. Выделение мелких объектов выполняется путём продвижения указателя на незанятую область с учётом выравнивания. Если незанятой области во всех блоках не хватает для выделения нового объекта, то выделяется новый блок. Если размер выделяемого объекта превышает значение константы NGX_MAX_ALLOC_FROM_POOL либо длину блока, то он полностью выделяется из кучи.

Таким образом, мелкие объекты выделяются очень быстро и имеют накладные расходы только на выравнивание.

nginx содержит модуль географической классификации клиентов по IP-адресу. В его основу входит база данных соответствия IP-адресов географическому региону, представленная в виде radix tree (сжатое префиксное дерево или сжатый лес) в оперативной памяти. nginx предварительно распределяет первые несколько уровней дерева таким образом, чтобы они занимали ровно 1 страницу памяти. Это гарантирует, что при поиске IP-адреса для первых нескольких узлов при трансляции адреса всегда найдётся запись в TLB.

Distributed vs Centralized Configuration

For administrators, one of the most readily apparent differences between these two pieces of software is whether directory-level configuration is permitted within the content directories.


Apache includes an option to allow additional configuration on a per-directory basis by inspecting and interpreting directives in hidden files within the content directories themselves. These files are known as files.

Since these files reside within the content directories themselves, when handling a request, Apache checks each component of the path to the requested file for an file and applies the directives found within. This effectively allows decentralized configuration of the web server, which is often used for implementing URL rewrites, access restrictions, authorization and authentication, even caching policies.

While the above examples can all be configured in the main Apache configuration file, files have some important advantages. First, since these are interpreted each time they are found along a request path, they are implemented immediately without reloading the server. Second, it makes it possible to allow non-privileged users to control certain aspects of their own web content without giving them control over the entire configuration file.

This provides an easy way for certain web software, like content management systems, to configure their environment without providing access to the central configuration file. This is also used by shared hosting providers to retain control of the main configuration while giving clients control over their specific directories.


Nginx does not interpret files, nor does it provide any mechanism for evaluating per-directory configuration outside of the main configuration file. This may be less flexible than the Apache model, but it does have its own advantages.

The most notable improvement over the system of directory-level configuration is increased performance. For a typical Apache setup that may allow in any directory, the server will check for these files in each of the parent directories leading up to the requested file, for each request. If one or more files are found during this search, they must be read and interpreted. By not allowing directory overrides, Nginx can serve requests faster by doing a single directory lookup and file read for each request (assuming that the file is found in the conventional directory structure).

Another advantage is security related. Distributing directory-level configuration access also distributes the responsibility of security to individual users, who may not be trusted to handle this task well. Ensuring that the administrator maintains control over the entire web server can prevent some security missteps that may occur when access is given to other parties.

Keep in mind that it is possible to turn off interpretation in Apache if these concerns resonate with you.

Компания Nginx

Запрос «» перенаправляется сюда. На эту тему нужно создать отдельную статью.

Для разработки коммерческих продуктов Игорь Сысоев создал в июле 2011 года компанию Nginx. Разработка ведётся в офисе, находящемся в Москве, для продаж создана американская «дочка» — Nginx Inc. В феврале 2012 компания начала предоставлять платные услуги, были введены три пакета технической поддержки — Premium, Advanced и Essential, в рамках которых подписчики получали услуги по установке, настройке производительности, конфигурации, сопровождению, содействию в проектировании, окончательной оптимизации.

В декабре 2011 года компания привлекла 3 млн долларов от пула инвесторов (в раунде лидировал фонд ; соинвесторами выступили фонды Runa Capital и семейный фонд Майкла Делла .

В октябре 2013 компания привлекла ещё 10 млн долларов. Ведущим инвестором выступил фонд ; соинвесторами выступили все фонды предыдущего раунда, а также Аарон Леви, глава

9 декабря 2014 было объявлено о привлечении дополнительных инвестиций в размере 20 млн долларов. Возглавил раунд венчурный фонд New Enterprise Associates при участии фондов , Runa Capital, (бывший BV Capital) и гендиректора Nginx Гуса Робертсона.

11 марта 2019 года компания F5 Networks объявила о покупке Nginx за 670 млн долларов, сделка была завершена 9 мая 2019 года.

12 декабря 2019 года стало известно, что корпорация Rambler (46,5 % которой принадлежит Сбербанку России) заявила исключительные права на исходные тексты nginx, отдельные СМИ сообщали о проведении обыска в офисе компании Nginx и об уголовном деле по ст. 146 УК РФ (Нарушение авторских и смежных прав). 18 мая 2020 года дело прекращено по пункту 1 части 1 статьи 24 УПК РФ (отсутствие события преступления).

Connection Handling Architecture

One big difference between Apache and Nginx is the actual way that they handle connections and traffic. This provides perhaps the most significant difference in the way that they respond to different traffic conditions.


Apache provides a variety of multi-processing modules (Apache calls these MPMs) that dictate how client requests are handled. Basically, this allows administrators to swap out its connection handling architecture easily. These are:

  • mpm_prefork: This processing module spawns processes with a single thread each to handle request. Each child can handle a single connection at a time. As long as the number of requests is fewer than the number of processes, this MPM is very fast. However, performance degrades quickly after the requests surpass the number of processes, so this is not a good choice in many scenarios. Each process has a significant impact on RAM consumption, so this MPM is difficult to scale effectively. This may still be a good choice though if used in conjunction with other components that are not built with threads in mind. For instance, PHP is not thread-safe, so this MPM is recommended as the only safe way of working with , the Apache module for processing these files.
  • mpm_worker: This module spawns processes that can each manage multiple threads. Each of these threads can handle a single connection. Threads are much more efficient than processes, which means that this MPM scales better than the prefork MPM. Since there are more threads than processes, this also means that new connections can immediately take a free thread instead of having to wait for a free process.
  • mpm_event: This module is similar to the worker module in most situations, but is optimized to handle keep-alive connections. When using the worker MPM, a connection will hold a thread regardless of whether a request is actively being made for as long as the connection is kept alive. The event MPM handles keep alive connections by setting aside dedicated threads for handling keep alive connections and passing active requests off to other threads. This keeps the module from getting bogged down by keep-alive requests, allowing for faster execution. This was marked stable with the release of Apache 2.4.

As you can see, Apache provides a flexible architecture for choosing different connection and request handling algorithms. The choices provided are mainly a function of the server’s evolution and the increasing need for concurrency as the internet landscape has changed.


Nginx came onto the scene after Apache, with more awareness of the concurrency problems that would face sites at scale. Leveraging this knowledge, Nginx was designed from the ground up to use an asynchronous, non-blocking, event-driven connection handling algorithm.

Nginx spawns worker processes, each of which can handle thousands of connections. The worker processes accomplish this by implementing a fast looping mechanism that continuously checks for and processes events. Decoupling actual work from connections allows each worker to concern itself with a connection only when a new event has been triggered.

Each of the connections handled by the worker are placed within the event loop where they exist with other connections. Within the loop, events are processed asynchronously, allowing work to be handled in a non-blocking manner. When the connection closes, it is removed from the loop.

This style of connection processing allows Nginx to scale incredibly far with limited resources. Since the server is single-threaded and processes are not spawned to handle each new connection, the memory and CPU usage tends to stay relatively consistent, even at times of heavy load.

Оптимизация работы с файлами

Пример настроенного nginx.conf:

http {   …     sendfile      on;     aio           on;     tcp_nopush    on;     open_file_cache max=100000 inactive=20s;     open_file_cache_valid 45s;     open_file_cache_min_uses 2;     open_file_cache_errors on;     … }

sendfile позволяет использовать более совершенный системный вызов, который обеспечивает прямую передачу файла (без системных вызовов read + write).

aio включает использование асинхронного обращения к файлам, что избавит от очередей запросов.

tcp_nopush позволит передавать заголовок ответа и начало файла в одном пакете.

open_file_cache по умолчанию выключена. Задает настройку для кэширования информации о файлах, с которыми работает nginx. По умолчанию, выключено.

open_file_cache_valid задает время, через которое веб-сервер будет проверять актуальность данных. По умолчанию, 60 секунд.

open_file_cache_min_uses задает минимальное число обращений к файлу, чтобы дескриптор файла оставался открытым в кэше.

open_file_cache_errors включает или выключает кэширование ошибок.

Также вы можете найти инструкции по тюнингу, где говорится об опции tcp_nodelay. Ее менять не нужно, так как по умолчанию она уже включена.

Для того, чтобы aio заработал в FreeBSD, необходимо выполнить следующее.

kldload aio

Для автоматической подгрузки модуля во время включения нашего веб-сервера:

ee /boot/loader.conf

… aio_load=»YES»

Открываем на редактирование файл с настройками лимитов для пользователей и групп:

vi /etc/security/limits.conf

Добавим строки:

… nginx           hard    nofile          199680 nginx           soft    nofile          65535 …

* в данном примере мы задаем ограничение для пользователя nginx на количество открытых файлов.

Зададим ограничение для текущей загрузки:

ulimit -n 65536

С этим читают