As mentioned earlier, Nginx does not derive a process or thread for each connection, but rather the worker process accepts a new request by listening on a shared socket and uses an efficient loop to handle thousands of connections. Nginx does not use arbitrators or distributors to distribute connections, this work is done by the operating system kernel mechanism. The listener sockets are initialized at startup, and the worker process accepts, reads requests, and outputs responses through these sockets.
The event-handling loop is the most complex part of the Nginx worker code, which contains complex internal calls and relies heavily on the idea of asynchronous task processing. Asynchronous operations are implemented through Modularity, event notifications, a number of callback functions, and fine-tuning timers. In general, the basic principle is to be as non-blocking as possible. The only scenario in which the Nginx worker process is blocked is insufficient disk performance.
Because Nginx does not derive a process or thread for each connection, memory usage is very economical and efficient in most cases. It also saves CPU time because the process or thread is not frequently generated and destroyed. What Nginx does is to check the state of the network and storage, initialize the new connection and add it to the main loop, and asynchronous processing will not be released from the main loop until the end of the request. With well-designed system calls and an accurate implementation of supporting interfaces such as memory pools, Nginx typically achieves low CPU usage in extreme load situations.
Nginx derives multiple worker processes to process connections, so it is well-utilized for multicore CPUs. Typically a separate worker process uses a single processor core, which makes full use of multicore architectures and avoids thread jitter and locks. There is no resource scarcity within a single-threaded worker process, and the resource control mechanism is isolated. This model also allows for scaling between physical storage devices, increasing disk utilization to avoid disk I/O-caused blocking. Distributing workloads across multiple worker processes can ultimately make server resources more efficient to use.
For some disk usage and CPU load patterns, the number of Nginx worker processes should be adjusted. The rules here are more basic, and the system administrator should try several configurations based on the load. Generally recommended: If the load pattern is CPU intensive, such as handling a large number of TCP/IP protocols, using SSL, or compressing data, the Nginx worker process should match the number of CPU cores, if it is disk intensive, such as providing multiple content services from storage, or a large number of proxy services, The number of worker processes should be 1.5 to twice times the number of CPU cores. Some engineers determine the number of worker processes based on the number of isolated storage units, although the validity of this method depends on the type of disk storage configuration.
One of the main problems that Nginx developers will address in the next release is how to avoid disk I/O blocking. Currently, if there is not enough storage performance to serve the disk operations of a worker process, the process is blocked on disk read and write operations. Some mechanisms and configuration directives are used to mitigate this disk I/O blocking scenario, most notably Sendfile and AIO directives, which can often reduce disk utilization. The installation nginx should be planned based on the data set, the number of available memory, and the underlying storage architecture.
Another problem with the current worker model is that support for embedded scripts is limited. For example, the standard Nginx release version only supports Perl as an embedded scripting language. The reason for this is simple: the embedded script is likely to block on any operation or exit abnormally, both of which cause the worker process to hang and affect thousands of connections at the same time. Simpler scripts, more reliable embedding of nginx, and more suitable for a wide range of applications have been included in the plan.
Nginx Process Role
Nginx runs multiple processes in memory, one master process and multiple worker processes. There are also special-purpose processes, such as cache loading and cache management processes. In the Nginx 1.x version, all processes are single-threaded, using shared memory as the inter-process communication mechanism. The master process runs with the root user right, and other processes run with unprivileged user rights.
The master process is responsible for reading and verifying configuration files, creating, binding, closing sockets, starting, terminating, maintaining the configured number of worker processes, not interrupting service refresh profiles, not disrupting service upgrades (starting new programs or rolling back when needed), reopening log files ; Compile embedded Perl script; The worker process accepts, processes connections from the client, provides reverse proxy and filtering capabilities, and all the other features that Nginx has. Because the worker process is the actual performer of the daily operation of the Web server, the system administrator should keep an eye on the worker process for monitoring Nginx instance behavior.
The cache loading process is responsible for checking the cache data on the disk and maintaining the database of cached metadata in memory. Basically, the cache loading process uses a specific, well-allocated directory structure to manage the files already stored on disk, prepares it for Nginx, traverses the directory, checks the cached content metadata, and updates the associated shared memory entries when all the data is available.
The cache management process is primarily responsible for cache expiration and invalidation. It is resident in memory when Nginx is working normally and is restarted by the master process when there is an exception.
Introduction to Nginx cache
Nginx uses tiered data storage to implement caching on the file system. The cache primary key is configurable, and the cached content can be controlled using different specific request parameters. The cache primary key and metadata are stored in shared memory segments, which are accessible by the cache loading process, the cache management process, and the worker process. Caching files in memory is not currently supported, but can be optimized with the operating system's virtual file system mechanism. Each cached response is stored to a different file on the file system, and the Nginx configuration directive controls the level of storage (in stages and nomenclature). If the response needs to be cached to the cache directory, the cached path and file name are obtained from the URL's MD5 hash value.
The process of caching the response to disk is as follows: When Nginx reads the response from the back-end server, the response content is first written to a temporary file outside the cache directory. After Nginx finishes the request processing, the temporary file is renamed and moved to the cache directory. If the temporary directory for the proxy function is located on another file system, the temporary files are copied once, so it is recommended that the temporary directory and the cache directory be placed on the same file system. If you need to clear the cache directory, you can also safely delete files. Some third-party extensions can control cache content remotely, and consolidating these features into the main release is already planned.
Nginx Working Process Model
