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

Optimization of Nginx configuration parameters

As a high-performance web server, Nginx can handle a large number of concurrent requests even without deliberately adjusting the configuration parameters.

The following configuration parameters are based on some tuning parameters on the Internet, which are used as a reference only and may not be suitable for your online business.

Worker process

Worker_processes this parameter indicates that several working processes are started. It is recommended to keep the same number of cores as native CPU. Each core CPU handles one process. Worker_rlimit_nofile represents the maximum number of file descriptors available for Nginx, which needs to be matched with the system's maximum descriptor. It is recommended to set it to 102400. You also need to execute ulimit-n 102400 in the system. You can also directly modify the configuration file / etc/security/limits.conf to add: # * soft nofile 655350 (remove the previous #) # * hard nofile 655350 (remove the previous #) worker_connections this parameter is used to configure the maximum number of connections handled by each Nginx worker process. This parameter also determines the maximum number of client requests that the Nginx server can handle (worker_processes * worker_connections). It is recommended to set this parameter to 10240, not too large.

Http and tcp connection

Use epoll uses the event-driven model of the epoll pattern, which is the best way under the Linux system. Multi_accept on enables each worker process to process multiple client requests simultaneously. Sendfile on uses the FD file transfer function of the kernel to reduce the switching between user mode and kernel mode, thereby improving server performance. Tcp_nopush on when tcp_nopush is set to on, the tcp_cork method is called for data transfer. Using this method has the effect that when the application generates data, the kernel does not encapsulate the packet immediately, but when the amount of data accumulates to a certain amount, it is encapsulated and then transmitted. Tcp_nodelay on does not cache data-sends (turn off the Nagle algorithm), which can improve the real-time performance of sending small data packets at high frequency. (about Nagle algorithm) [if you need to send some packet data frequently, such as 1 byte, take IPv4 as an example, each packet should be accompanied by a 40-byte header, that is, out of a total of 41 bytes of data, only 1 byte is the data we need. In order to solve this problem, the Nagle algorithm appears. It states that if the size of the packet meets the MSS, it can be sent immediately, otherwise the data will be put into the buffer and can not be sent until the packet that has been sent has been confirmed. Through such regulations, the number of packets in the network can be reduced, thus improving network performance. Keepalive_timeout defines the timeout for persistent connections. It is recommended that 30s. It may not be appropriate to be too short or too long. Of course, it is best to adjust this parameter dynamically according to the business itself. Keepalive_requests defines the maximum number of requests each client can make when the client and the server are in a persistent connection, which can be set to a large number, for example, if 50000.reset_timeout_connection on is set to on, when the client no longer sends requests to the server, the server is allowed to close the connection. If the client_body_timeout client does not finish loading body data within the specified time, it disconnects in seconds. The default is 60, which can be set to 10. The send_timeout timeout is the timeout for sending a response, that is, the Nginx server sends a packet to the client, but the client never receives the packet. If a connection exceeds the timeout defined by send_timeout, Nginx will close the connection. The unit is seconds, which can be set to 3.

Buffer and cache (the following configurations are for a single request)

Client_body_buffer_size when the client submits some data to the server using the POST method, it will first be written to the client_body_buffer. If the buffer is full, it will be written to a temporary file. It is recommended to adjust it to 128k. When a client_max_body_size browser sends a request with a larger HTTP body, it has a Content-Length field in its header, and the client_max_body_size is used to limit the size of the value shown by the Content-Length. This restricts the configuration of body to tell the user that the request is too large to be accepted without waiting for Nginx to receive all the HTTP packets. A 413 status code is returned. For example, a user tries to upload a 1GB file, and after receiving the header, Nginx finds that Content-Length exceeds the value defined by client_max_body_size, and sends a 413 (Request Entity Too Large) response directly to the client. If you set this value to 0, the limit is disabled and it is recommended to set it to 10m. Client_header_buffer_size sets the buffer size of the client header. 4k is recommended. Large_client_header_buffers will use this part of the buffer for larger header (more than client_header_buffer_size), two values, the first is the number, and the second is the size of each buffer. It is recommended that the parameter be set to 4 8kopen_file_cache. This parameter caches the following information: the file size and modification time of the open file descriptor; the directory information that exists; and the error message of the search file (there is no information such as unauthorized reading of the file). Format: open_file_cache max=size inactive=time;max sets the number of cache files, and inactive sets how long it takes to delete the cache after the file has not been requested. It is recommended to set open_file_cache max=102400 inactive=20s;open_file_cache_valid refers to how often to check the valid information of the cache. It is recommended to set it to 30s. The minimum number of times a file is used during the time of the inactive parameter in the open_file_cache_min_usesopen_file_cache directive. For example, setting this parameter to 1 means that if the file is not used once in inactive time, it will be removed. It is recommended to set it to 2.

Compress

For plain text content, Nginx can be compressed using gzip. Using compression technology can reduce the consumption of bandwidth.

Supported by ngx_http_gzip_module module

The configuration is as follows:

Gzip on; / / enable gzip function

Gzip_min_length 1024; / / set request resources to exceed this value before compression (in bytes)

Gzip_buffers 168k; / / sets the buffer size used for compression. The first number is the number, and the second is the size of each buffer.

Gzip_comp_level 6; / / sets the compression level, which ranges from 1 to 9. The compression level is the highest and consumes the most CPU resources.

Gzip_types text/plain application/x-javascript text/css application/xml image/jpeg image/gif image/png; / / specify which types of files need to be compressed

Gzip_disable "MSIE 6."; / / IE6 browser does not enable compression

Test:

Curl-I-H "Accept-Encoding: gzip, deflate" http://www.aminglinux.com/1.css

Journal

Increase the error log level, such as the crit level, and keep as few unimportant logs as possible. For access logs, if logging is not required, it can be turned off, and access logs for static resources can be closed.

Static files expire

For static files, you need to set an expiration time so that these resources can be cached to the client browser

Before the cache expires, the client no longer requests the same resources from the service period, thus saving bandwidth and resource consumption.

Examples of configurations are as follows:

Location ~ * ^. +. (gif | jpg | png | css | js) $

{

Expires 1d; / / 1d means 1 day, or 24 hours can be used to represent a day.

}

As a proxy server

In most cases, Nginx acts as an agent or load balancer.

Because the following parameters have been described in the previous section, only the corresponding configuration parameters are provided here:

Http

{

Proxy_cache_path / data/nginx_cache/ levels=1:2 keys_zone=my_zone:10m inactive=300s max_size=5g

...

Server

{

Proxy_buffering on

Proxy_buffer_size 4k

Proxy_buffers 2 4k

Proxy_busy_buffers_size 4k

Proxy_temp_path / tmp/nginx_proxy_tmp 1 2

Proxy_max_temp_file_size 20M

Proxy_temp_file_write_size 8k

Location / {proxy_cache my_zone;...;}}

}

SSL optimization

Reduce the number of worker_processes appropriately, because the ssl function requires the calculation of CPU. Use persistent connections, because each time a ssl session is established, it takes a certain amount of resources (encryption, decryption) to open the ssl cache, simplifying the "handshake" process between the server and the client. Ssl_session_cache shared:SSL:10m; / / cache is 10Mssl_session_timeout 10m; / / session timeout is 10 minutes

Adjust Linux kernel parameters

As a high-performance WEB server, it is not possible to just adjust the parameters of Nginx itself, because Nginx services rely on a high-performance operating system.

Here are a few common Linux kernel parameter optimization methods.

Net.ipv4.tcp_max_tw_buckets

For tcp connections, the status changes to timewait after communication between the server and the client. If a server is very busy and has a large number of connections, then the number of timewait will become larger and larger. After all, it also takes up a certain amount of resources, so there should be a maximum value. When this value is exceeded, the system will delete the earliest connection, which is always maintained at an order of magnitude. This value is determined by the parameter net.ipv4.tcp_max_tw_buckets. For CentOS7 system, you can use sysctl-a | grep tw_buckets to check its value. The default is 32768. You can lower it appropriately, for example, to 8000. After all, too many connections in this state will consume resources. But you should not set it to tens or hundreds, because the tcp connection in this state is also useful, if the same client communicates with the server again, you don't have to establish a new connection again. Use this old channel to save time and effort.

Net.ipv4.tcp_tw_recycle = 1

The purpose of this parameter is to quickly reclaim connections in the timewait state. Although it is mentioned above that the system will automatically delete connections in timewait state, wouldn't it be better to reuse such connections. So setting this parameter to 1 allows connections in the timewait state to be quickly recycled, which needs to be used in conjunction with the following parameters.

Net.ipv4.tcp_tw_reuse = 1

This parameter is set to 1 to reuse the connection in the timewait state for the new TCP connection, in conjunction with the above parameters.

Net.ipv4.tcp_syncookies = 1

In the tcp three-way handshake, the client initiates a syn request to the server. After receiving it, the server will also send a syn request to the client with ack confirmation. If the client disconnects directly from the server after sending the request and does not receive the request from the server, the server will retry many times. The retry process will last for a period of time (usually more than 30s), when the number of connections in this state is very large. The server will consume a lot of resources, resulting in paralysis, normal connections can not enter, this malicious semi-connection behavior is actually called syn flood***. Set to 1 to enable SYN Cookies, which can avoid the occurrence of the above syn flood***. When this parameter is enabled, after the server receives the ack of the client, it will ask the client to respond to a sequence number within a short period of time before sending the ack+syn to the client. If the client cannot provide the sequence number or the sequence number provided is incorrect, the client is considered illegal, so it will not send ack+syn to the client, let alone retry.

Net.ipv4.tcp_max_syn_backlog

This parameter defines the maximum number of tcp connections in the semi-connected state that the system can accept. The client sends a syn packet to the server, and after receiving it, the server will record it. This parameter determines how many such connections can be recorded at most. In CentOS7, the default is 256. when there is syn flood***, it is easy to paralyze the server if it is too small. In fact, the server does not consume too many resources (cpu, memory, etc.), so you can increase it appropriately, such as 30000.

Net.ipv4.tcp_syn_retries

This parameter applies to the client and defines the maximum number of retries to initiate the syn. The default is 6, and it is recommended to change to 2.

Net.ipv4.tcp_synack_retries

This parameter is applicable to the server. It defines the maximum number of retries to initiate syn+ack. The default is 5. It is recommended to change to 2, which can prevent syn flood appropriately.

Net.ipv4.ip_local_port_range

This parameter defines the port range. The system reserves ports of 1024 or less by default, and the above part is a custom port. This parameter applies to the client. When the client establishes a connection with the server, such as accessing port 80 of the server, the client randomly opens a port and initiates a connection with the server. This parameter defines the range of random ports. The default is 32768 61000, and it is recommended to adjust to 1025 61000.

Net.ipv4.tcp_fin_timeout

Among the states of tcp connections, one on the client is the FIN-WAIT-2 state, which is the state before the state transitions to the timewait. This parameter defines the timeout for this connection state that does not belong to any process. The default value is 60, and it is recommended to adjust to 6.

Net.ipv4.tcp_keepalive_time

In the tcp connection state, one is the established state, and only in this state can the client and server communicate. Normally, when the communication is completed, the client or server will tell the other party to close the connection, and the status will change to timewait. If the client does not tell the server, and the server does not tell the client to shut down (for example, the client is disconnected), this parameter is needed to determine. For example, the client has been disconnected, but the status of this connection on the server is still established. In order to confirm whether the client is disconnected, the server needs to send a probe packet every once in a while to check whether the other party is online. This time is determined by this parameter. Its default value is 7200 seconds, and it is recommended to set it to 30 seconds.

Net.ipv4.tcp_keepalive_intvl

This parameter is the same as the above parameter. The server initiates a probe within a specified period of time to check whether the client is online. If the client does not confirm it, the server cannot determine that the other party is not online, but has to try many times. This parameter defines the time to resend the probe, that is, how long it takes to initiate the probe again after the other party is first found to have a problem. The default is 75 seconds, which can be changed to 3 seconds.

Net.ipv4.tcp_keepalive_probes

The 10th and 11th parameters specify when to initiate the probe and how long it will be after the probe fails, but it does not define how many probes will be completed. This parameter defines the number of packets that initiate the probe. The default is 9, and it is recommended to set 2.

Settings and examples

By adjusting kernel parameters under Linux, you can edit the configuration file / etc/sysctl.conf directly, and then execute the sysctl-p command to take effect.

Combined with the kernel parameters analyzed above, the example is as follows

Net.ipv4.tcp_fin_timeout = 6

Net.ipv4.tcp_keepalive_time = 30

Net.ipv4.tcp_max_tw_buckets = 8000

Net.ipv4.tcp_tw_reuse = 1

Net.ipv4.tcp_tw_recycle = 1

Net.ipv4.tcp_syncookies = 1

Net.ipv4.tcp_max_syn_backlog = 30000

Net.ipv4.tcp_syn_retries = 2

Net.ipv4.tcp_synack_retries = 2

Net.ipv4.ip_local_port_range = 1025 61000

Net.ipv4.tcp_keepalive_intvl = 3

Net.ipv4.tcp_keepalive_probes = 2

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.