Shulou(Shulou.com)06/02 Report--

This article mainly explains why Nginx is so fast. Friends who are interested might as well take a look at it. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn why Nginx is so fast.

Process Model of Nginx

Nginx server, during normal operation:

Multiple processes: one Master process, multiple Worker processes

Master process: managing Worker process

External interface: receiving external operations (signals)

Internal forwarding: Worker is managed by signal depending on the external operation

Monitoring: monitor the running status of the worker process. If the worker process terminates abnormally, it automatically restarts the worker process.

Worker process: all Worker processes are equal

Actual processing: network requests, handled by the Worker process

Number of Worker processes: configured in nginx.conf, generally set to the number of cores to make full use of CPU resources, at the same time, avoid too many processes, avoid process competition for CPU resources, and increase the loss of context switching.

Think about:

Is the request processed and forwarded by connecting to the Nginx,Master process?

Which Worker process is selected to handle the request? Does the processing result of the request still go through the Master process?

HTTP connection establishment and request processing:

When Nginx starts, the Master process loads the configuration file

Master process, initializing the listening socket

Master process, fork out multiple Worker processes

The Worker process competes for a new connection, and the winner establishes a Socket connection through a three-way handshake and processes the request

Nginx high performance, high concurrency:

Nginx adopts: multi-process + asynchronous non-blocking mode (IO multiplexing epoll)

The complete process of the request:

Establish a connection

Read requests: parsing requests

Process the request

Respond to a request

The complete process of the request, corresponding to the underlying layer, is: read and write socket events

Event handling Model of Nginx

Http request in request:Nginx.

Basic HTTP Web Server mode of operation:

Receive the request: read the request line and the request header line by line, and read the request body after judging that the segment has the request body.

Process the request

Return response: according to the processing result, generate the corresponding HTTP request (response line, response header, response body)

Nginx is also the same routine, the overall process is consistent.

Modular architecture

The modules of nginx can basically be divided into the following types according to their functions:

Event module: build a framework of event handling mechanism independent of the operating system, and provide the handling of specific events. Including ngx_events_module, ngx_event_core_module and ngx_epoll_module. Which event handling module nginx uses depends on the specific operating system and compilation options.

Phase handler: this type of module is also referred to as a handler module directly. It is mainly responsible for processing the client request and generating the content to be responded, such as the ngx_http_static_module module, which is responsible for the static page request processing of the client and preparing the corresponding disk file for the response content output.

Output filter: also known as the filter module, is mainly responsible for processing the content of the output, you can modify the output. For example, you can do things like adding predefined footbar to all output html pages, or replacing the URL of output images.

Upstream: the upstream module implements the function of reverse proxy, forwards the real request to the back-end server, reads the response from the back-end server, and sends it back to the client. The upstream module is a special kind of handler, except that the response content is not really generated by itself, but read from the back-end server.

Load-balancer: a load balancing module that implements specific algorithms. Among many back-end servers, select a server as the forwarding server for a request.

Analysis of common problems

Nginx vs. Apache

Network IO model:

Nginx:IO Multiplexing, epoll (kqueue on freebsd)

High performance

High concurrency

Take up less system resources

Apache: blocking + multiprocess / multithreading

More stable, less bug

Richer modules

Scene:

When processing multiple requests, you can use: IO multiplexing or blocking IO + multithreading

IO multiplex: a thread that tracks multiple socket states, which one is ready, which one is read and written

Blocking IO + multithreading: create a new service thread for each request

Thinking: what are the applicable scenarios for IO multiplexing and multithreading?

IO multiplexing: the request processing speed of a single connection has no advantage, so it is suitable for IO-intensive scenarios and event-driven.

Large concurrency: use only one thread to handle a large number of concurrent requests, reduce the context switching loss, and do not need to consider the concurrency problem, so you can handle more requests relatively.

Consume less system resources (no thread scheduling overhead)

Suitable for long connections (multi-thread mode long connections can easily lead to too many threads and frequent scheduling)

Blocking IO + multithreading: easy to implement, independent of system calls, suitable for CPU-intensive scenarios

Every thread needs time and space.

When the number of threads increases, the thread scheduling overhead increases exponentially.

Maximum number of Nginx connections

Basic background:

Nginx is a multi-process model, and Worker processes are used to process requests.

The number of connections to a single process (file descriptor fd), with an upper limit (nofile): ulimit-n

The maximum number of connections of a single worker process configured on Nginx: the upper limit of worker_connections is nofile.

Number of worker processes configured on Nginx: worker_processes

Therefore, the maximum number of connections for Nginx:

Maximum number of connections for Nginx: number of Worker processes x maximum number of connections for a single Worker process

Above is the maximum number of connections when Nginx is used as a general-purpose server

The maximum number of connections that can be served when Nginx is used as a reverse proxy server: (number of Worker processes x maximum number of connections for a single Worker process) / 2.

When Nginx reverse proxy, the connection between Client and back-end Web Server will be established, occupying 2 connections

Think about:

Each socket opened takes up one fd

Why is there a limit to the number of fd that a process can open?

IO model

Scene:

When processing multiple requests, you can use: IO multiplexing or blocking IO + multithreading

IO multiplex: a thread that tracks multiple socket states, which one is ready, which one is read and written

Blocking IO + multithreading: create a new service thread for each request

Thinking: what are the applicable scenarios for IO multiplexing and multithreading?

IO Multiplexing: there is no advantage in request processing speed for a single connection

Large concurrency: use only one thread to handle a large number of concurrent requests, reduce the context switching loss, and do not need to consider the concurrency problem, so you can handle more requests relatively.

Consume less system resources (no thread scheduling overhead)

Suitable for long connections (multi-thread mode long connections can easily lead to too many threads and frequent scheduling)

Blocking IO + multithreading: easy to implement and can be independent of system calls.

Every thread needs time and space.

When the number of threads increases, the thread scheduling overhead increases exponentially.

Comparison between select/poll and epoll

For details, please refer to:

The comparison among the three select poll epoll

Select/poll system call:

/ / select system call int select (int maxfdp,fd_set * readfds,fd_set * writefds,fd_set * errorfds,struct timeval * timeout); / / poll system call int poll (struct pollfd fds [], nfds_t nfds, int timeout)

Select:

To query whether there is a ready fd in fd_set, you can set a timeout, and return when there is fd (File descripter) ready or timeout.

Fd_set is a collection of bits whose size is the constant when compiling the kernel. The default size is 1024.

Features:

The number of connections is limited. The number of fd that fd_set can represent is too small.

Linear scan: to determine whether the fd is ready, you need to traverse one side of the fd_set

Data replication: user space and kernel space, replication connection ready state information

Poll:

The number of connections limit has been resolved:

Poll replaces fd_set in select with an array of pollfd

Solve the problem that the number of fd is too small

Data replication: user space and kernel space, replication connection ready state information

Epoll: event event driven

Event mechanism: avoiding linear scanning

Register a listening event for each fd

When fd changes to ready, add fd to the ready list

Number of fd: unlimited (OS level limit, how many fd can be opened by a single process)

Select,poll,epoll:

The Mechanism of Ipaw O Multiplexing

Icano multiplexing uses a mechanism to monitor multiple descriptors, and once a descriptor is ready (usually read-ready or write-ready), it can inform the program to read and write accordingly.

Monitor multiple file descriptors

But select,poll,epoll is essentially synchronous Imax O:

The user process is responsible for reading and writing (copying from kernel space to user space). During the read and write process, the user process is blocked.

Asynchronous IO, which does not require user processes to read and write, asynchronous IO, is responsible for copying from kernel space to user space.

Concurrent processing capability of Nginx

About the concurrent processing capabilities of Nginx:

The number of concurrent connections is generally optimized, and the peak value can be maintained at about 1 to 3 weeks. (the number of cores of memory and CPU is different, there will be room for further optimization.)

At this point, I believe you have a deeper understanding of "why Nginx is so fast". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.