Summarize how to optimize Nginx performance under high concurrency

We will meet in the end, in a place where there is no darkness. ~George, 1984

Nginx, like Apache, is a web server. Based on the REST architectural style, it uses the Uniform Resource Descriptor (URl) or the Uniform Resource Locator (URL) as the communication basis and provides various network services through the HTTP protocol.

Apache has a long history and is the undisputed world's largest server. It has many advantages: stable, open source, cross-platform and so on. It has been too long since it appeared, and when it emerged, the Internet industry was far less developed than it is today. So it is designed to be a heavyweight. It does not support high concurrent servers. Running tens of thousands of concurrent accesses on Apache will cause the server to consume a large amount of memory. The operating system's switching between processes or threads also consumes a large amount of CPU resources, resulting in a decrease in the average response speed of HTTP requests.

All these determined that Apache could not become a high-performance WEB server, and the lightweight and high-concurrency server Nginx came into being.

Features

It is a high-performance HTTP and reverse proxy web server that provides lightweight IMAP/POP3/SMTP services. It was released on October 4, 2004 (the first public version 0.1.0). The 1.4.0 stable version of Nginx was released on April 24, 2013. Written in C language, Nginx is a cross-platform server. Nginx has its own function library, and except for zlib, PCRE and OpenSSL, the standard module only uses system C library functions.

Advantages

Occupies less memory (in 3W concurrent connections, the 10 opened nginx processes consume about 150M of memory) High concurrency capability (official tests can support 5W concurrent connections, and in actual production environments it can reach 2-3W concurrent connections) Simple (configuration files are easy to understand) Price (free, open source) Supports Rewriter rewriting (can divide HTTP requests into different backend server groups according to domain names and URLs) Built-in health check (if several services on the nginx backend are down, it will not affect frontend access, and can automatically detect service status) Save bandwidth (supports GZIP compression, and can add browser local cache headers)
High stability, reverse proxy, rarely downtime. Users of nginx websites in mainland China include: Baidu, JD.com, Sina, NetEase, Tencent, Taobao, etc.

Function: web server, lightweight; load, balancing; cache; high concurrency

Application scenarios: proxy server; IP load, static load; dynamic and static separation; current limiting, health monitoring

Installation and commands

Install:

sudo apt-get install nginx

View Version

nginx -v                  
nginx version: nginx/1.18.0 (Ubuntu)

Basic Commands

# The specific location of nginx's access page (welcome to nginx) vi /usr/share/nginx/html/index.html
# Access IP
curl 192.168.100.111
#Shut down the nginx process nginx -s stop
# Start the nginx process /usr/sbin/nginx # The nginx installed by yum can also use servic nginx start
# Check if the configuration file is correct nginx –t
# Reload the configuration file nginx –s reload
# View the log tail -f filename #Display file defaults to 10 lines, refresh the display # Example: tail -f /var/log/lvs-agent.log tail -f /etc/nginx/nginx.conf
# View the last few lines of the file tail -n line number file name example: tail -n 100 /var/log/aa.log
# Delete the network card ip
ip addr del 192.168.11.5/32 dev lo (lo eth1 eth2)
# lvs clears all cluster services ipvsadm –C
# Get the IP value of eth0 network card ip a|grep eth0|grep inet|awk '{print $2}'|cut -d "/" -f1
# Verify that the IP or URL is available and return 200
curl -I -m 10 -o /dev/null -s -w %{http_code} 10.110.26.10:8080
# Start the jar package in the background nohup java -jar /usr/sbin/project name.jar >>/var/log/project name.log 2>&1 &
# Check whether the previous command was executed successfully. Return 0 if it is executed successfully. Otherwise, echo $?
# Check whether the nginx process is started. This command is used in the code to determine whether the nginx process is started. If you only use ps aux | grep nginx, even if it is not started, the content will be returned, affecting the judgment ps aux | grep nginx | ​​greo –v grep

Configuration Files

nginx.conf

# nginx.conf
# Global configuration area user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
# Network event configuration area events {
	worker_connections 768;
	# multi_accept on;
}
# HTTP module http {
	##
	# HTTP Global Settings ##
	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	keepalive_timeout 65;
	types_hash_max_size 2048;
	# server_tokens off;
	# server_names_hash_bucket_size 64;
	# server_name_in_redirect off;
	include /etc/nginx/mime.types;
	default_type application/octet-stream;
	##
	# SSL Settings ##
	ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
	ssl_prefer_server_ciphers on;
	##
	# Log Settings ##
	access_log /var/log/nginx/access.log;
	error_log /var/log/nginx/error.log;
	##
	# Resource Compression Settings ##
	gzip on; # Enabled by default # gzip_vary on;
	# gzip_proxied any;
	# gzip_comp_level 6;
	# gzip_buffers 16 8k;
	# gzip_http_version 1.1;
	# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
	##
	# Virtual Host Configuration ##
	include /etc/nginx/conf.d/*.conf;
	include /etc/nginx/sites-enabled/*;
}

/etc/nginx/sites-enabled/*

server { # Virtual host configuration listen 80 default_server; # Listening port listen [::]:80 default_server;
	# SSL Configuration #
	# listen 443 ssl default_server;
	# listen [::]:443 ssl default_server;
	#
	# Note: You should disable gzip for SSL traffic.
	# See: https://bugs.debian.org/773332
	#
	# Read up on ssl_ciphers to ensure a secure configuration.
	# See: https://bugs.debian.org/765782
	#
	# Self signed certs generated by the ssl-cert package
	# Don't use them in a production server!
	#
	# include snippets/snakeoil.conf;	
	# Data cache location root /var/www/html;
	# Add index.php to the list if you are using PHP
	index index.html index.htm index.nginx-debian.html;	
	#Domain name, there can be multiple server_name _;	
	# Perform a reverse proxy on / location / {
		# First attempt to serve request as file, then
		# as directory, then fall back to displaying a 404.
		# uwsgi_pass 127.0.0.1:8000;
		#include /etc/nginx/uwsgi_params;
		try_files $uri $uri/ =404;
	}
	# pass PHP scripts to FastCGI server
	#
	#location ~ \.php$ {
	# include snippets/fastcgi-php.conf;
	#
	# # With php-fpm (or other unix sockets):
	# fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
	# # With php-cgi (or other tcp sockets):
	# fastcgi_pass 127.0.0.1:9000;
	#}
	# deny access to .htaccess files, if Apache's document root
	# concurs with nginx's one
	#
	#location ~ /\.ht {
	# deny all;
	#}
}

Proxy mode and reverse proxy configuration

Forward proxy:

It is a server (proxy server) located between the client (user A) and the origin server (origin server) (target server). In order to obtain content from the origin server, the client sends a request to the proxy server and specifies the target (origin server). The proxy server then forwards the request to the origin server and returns the obtained content to the client. The client must perform some special configuration to use a forward proxy. Generally speaking, if there is no special explanation, proxy technology refers to forward proxy technology by default.

It is equivalent to a professional intermediary, and the client and the actual server cannot communicate. The client knows that he is an intermediary.

Reverse proxy:

In contrast to a forward proxy, it appears to the client like an origin server and the client does not need to perform any special configuration. The client sends a normal request to the content in the reverse proxy's namespace, and the reverse proxy then determines where to forward the request (the original server) and returns the obtained content to the client, just as if the content originally belonged to it.

It is equivalent to a person who buys and sells a house. When buying a house, there is a buyer relative to the seller, and when selling a house, there is a seller relative to the buyer.
The client does not know that it is a proxy server, and the server also thinks that it is just a client and not a proxy server.

Transparent Proxy:

Transparent proxy means that the client does not need to know the existence of the proxy server at all. It adapts your request fields (messages) and transmits the real IP. Note that an encrypted transparent proxy is an anonymous proxy, which means you don’t need to set up a proxy. An example of transparent proxy practice is the behavior management software used by many companies nowadays.

# Reverse proxy is disabled by default # Upstream localhost is a third-party module that balances upstream localhost {
	# Actual server server 192.168.136.133:8081;
	server 192.168.136.133:8081;
	server 192.168.136.133:8081;
} 
# load server {
	listen 80 # proxy server port server_name localhost;
	location / {
		proxy_pass http://localhost; # Send the request to one of the actual servers }
}

Load balancing method:

Polling method (default)

Weighted Round Robin (Weight)

Fair

url_hash

Source address hashing

Least_conn

Separation of static and dynamic

Nginx dynamic and static separation simply means separating dynamic and static requests. It cannot be understood as simply physically separating dynamic pages from static pages.

Strictly speaking, dynamic requests should be separated from static requests. It can be understood as using Nginx to process static pages and Tomcat to process dynamic pages.

From the current implementation perspective, dynamic and static separation can be roughly divided into two types:

• One is to simply separate the static files into a separate domain name and put them on a separate server, which is also the mainstream solution currently.
• One is to publish dynamic and static files together and separate them through nginx

mkdir static #Store static files

server { # Virtual host configuration listen 80 default_server; # Listening port listen [::]:80 default_server;
	
	# Data cache location root /var/www/html;

	# Add index.php to the list if you are using PHP
	index index.html index.htm index.nginx-debian.html;
	
	#Domain name, there can be multiple server_name _;
	
	# Perform a reverse proxy on / location / {
		# First attempt to serve request as file, then
		# as directory, then fall back to displaying a 404.
		# uwsgi_pass 127.0.0.1:8000;
		#include /etc/nginx/uwsgi_params;
		try_files $uri $uri/ =404;
	}
	# If it is one of these file extensions, look for it here location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css) $ {
		root /static;
		expires 30d; # Cache validity period }
}

Log Management

Log Format

The log is generated to the Nginx root directory logs/access.log file. The default log format is "main". You can also customize the default log format "main".

og_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
$remote_addr: client IP address (proxy server, displays proxy service IP)
$remote_user: Used to record the user name of the remote client (usually "-")
$time_local: used to record access time and time zone $request: used to record the requested URL and request method $status: response status code, for example: 200 success, 404 page not found, etc.
$body_bytes_sent: The number of bytes of the file body content sent to the client

Log cutting

Nginx log files do not have a rotate function

Write a log file every day. We can write an nginx log cutting script to automatically cut the log file.

• The first step is to rename the log file (don't worry about losing the log file because nginx can't find the log file after renaming. Before you reopen the log file with the original name, nginx will still write the log to the file you renamed. Linux locates the file by the file descriptor rather than the file name)
• The second step is to send USR1 signal to the nginx main process
  After receiving the signal, the nginx main process will read the log file name from the configuration file and reopen the log file (named after the log file in the configuration file), and use the user of the worker process as the owner of the log file. After reopening the log file, the nginx main process will close the log file with the same name and notify the worker process to use the newly opened log file. The worker process will immediately open the new log file and close the log file with the same name, and then you can process the old log file. [Or restart nginx service]

The script for automatically cutting nginx logs every minute is as follows:

Create a new shell script

High Concurrency Architecture Analysis

What is high concurrency?

High concurrency is one of the factors that must be considered in the design of Internet distributed system architecture. It usually means that the system is designed to be able to process many requests in parallel at the same time.

Some commonly used indicators related to high concurrency include response time, throughput, query per second (QPS), number of concurrent users, etc.

• Response time: The time it takes for the system to respond to a request
• Throughput: The number of requests processed per unit time.
• QPS: Number of requests per second

How to improve the system's concurrency capabilities?

There are two main methodological approaches to improving the concurrent capabilities of Internet distributed architecture design: vertical expansion (ScaleUp) and horizontal expansion (ScaleOut).

Vertical expansion: Improve the processing power of a single machine. There are two ways to scale vertically.

• Enhance stand-alone hardware performance
• Improving the performance of single-machine architecture

In the early days when Internet business was developing very rapidly, if budget was not an issue, it was strongly recommended to use the method of "enhancing stand-alone hardware performance" to improve system concurrency capabilities, because at this stage, the company's strategy was often to develop business in a time-sensitive manner, and "enhancing stand-alone hardware performance" was often the fastest method.

Whether it is improving the hardware performance of a single machine or improving the performance of a single machine architecture, there is a fatal shortcoming: the performance of a single machine always has its limits. Therefore, the ultimate solution for high concurrency in Internet distributed architecture design is horizontal expansion.

Horizontal expansion: System performance can be expanded linearly by simply increasing the number of servers.

Servers have limits

Three ways to achieve

limit_conn_zone (limit connection flow)

limit_req_zone (limit request flow)

ngx_http_upstream_module (backend service restrictions)

Here is a small tool: limit the download of test tools

yum install http-tools -y

Limiting connection flow

http {
	# binary_remote_addr:IP
	# zone=one:10m; Apply for a 10M space to store the connected IP
	limit_conn_zone $binary_remote_addr zone=one:10m;
	
	server {
		# In the zone area, 10 connections are released each time and processed by nginx limit_conn one 10;
	}
}

Limiting request flow (rate limiting)

http {
	# rate means that each connection can send one connection per second limit_req_zone $binary_remote_addr zone=req_one:10m rate=1r/s;
	
	server {
		# brust: token, add one at a time, error 503 will be reported after 120 tokens are issued
		limit_req zone=req_one brust=120;
	}
}

Background service restrictions

This module provides the backend current limiting function we need

This module has a parameter: max_conns can limit the flow of the server, but it can only be used in the commercial version of nginx

After nginx1.11.5, the official has separated this parameter from the commercial version, which means that as long as we upgrade the widely used nginx1.9.12 and 1.10 versions in production, we can use it

server {
	# max_conns maximum number of receiving services server 127.0.0.1:8080 max_conns=100;
}

Security Configuration

Version security

http {
	server_tokens off;
}

IP Security

http {
	location / {
		allow 127.0.0.1; # Whitelist deny all; # Blacklist }
}

File Security

http {
	location /logs{
		autoindex on; # Display directory root /static;
	}
	location ^/logs~*\.(log|txt)$ {
		add_header Content_Type text/plain;
		root /static;
	}
}

Connection security

http {
	# SSL settings
}

Nginx Optimization

Adjust the main configuration file of Nginx to increase the concurrency

worker_processes 2;# Adjust to be consistent with CPU events {
	# Maximum number of concurrent connections per worker worker_connection 65535;
}

Nginx long connection: After HTTP1.1, the HTTP protocol supports persistent connections, that is, long connections. The advantage is that multiple HTTP requests and responses can be transmitted on one TCP connection.

Nginx long connection and short connection can enhance the disaster recovery capability of the server

Reduces the cost and latency of establishing and closing connections. If we use nginx as a reverse proxy or load balancing, the long connection request from the client will be converted into a short connection and sent to the server. In order to support long connections, we need to do some configuration on the nginx server.

When using nginx, if you want to achieve long connections, we must do the following two things:

• From client to nginx is a long connection (events)
• From nginx to server is a long connection (http)

For the client, nginx actually plays the role of a server. Conversely, for the server, nginx is a client.

events {
	# Keepalive timeout, the default is 60s, remember that this parameter cannot be set too large! Otherwise, many invalid http connections will occupy the number of nginx connections, and eventually nginx will crash!
	keepalive_timeout 60;
}
http {
	keepalive_timeout 60;
}

Nginx Compression

Gzip compression function: The compression function can be enabled before sending the response message to the client, which can effectively save bandwidth and increase the speed of responding to the client. Compression will consume nginx's CPU performance.

Gzip compression can be configured in http, server and location modules

http {
    #gzip module settings #Turn on compression gzip on;
    # Set the minimum number of bytes allowed for compressed pages. The number of bytes for a page is obtained from the content-length in the header.
    The default value is 0, which compresses pages regardless of their size. It is recommended to set it to a number of bytes greater than 2k. If it is less than 2k, the compression may increase.
    gzip_min_length 2k;
    # Set the system to obtain several units of cache to store the gzip compression result data stream. For example, 4 4k means that the memory is requested in units of 4k, which is four times the original data size in units of 4k. 4 8k means the unit is 8k, according to the original data size
    Request 4 times the memory of the unit.
    # If not set, the default value is to apply for the same size of memory space as the original data to store the gzip compression result.
    gzip_buffers 4 16k;
    #Compression level, 1-10, the larger the number, the better the compression, but also the more CPU time it takes gzip_comp_level 5;
    # Default value: gzip_types text/html (js/css files are not compressed by default)
    # Compression type, match the MIME type for compression # Wildcard text/* cannot be used
    # (regardless of whether it is specified) text/html is compressed by default # To set which type of text file to compress, refer to conf/mime.types
    gzip_types text/plain application/xjavascript text/css application/xml;
    # The value is 1.0 and 1.1, indicating whether to compress http protocol 1.0. If 1.0 is selected, both 1.0 and 1.1 can be compressed. gzip_http_version 1.0
    # Disable compression for IE6 and below gzip_disable "MSIE [1-6]\.";
    # Default value: off
    # Enable when Nginx is used as a reverse proxy, turn on or off the results returned by the backend server. The prerequisite for matching is that the backend server must return a header containing "Via".
    # off - turns off compression of all proxy result data # expired - enables compression if the "Expires" header is included # no-cache - enables compression if the "Cache-Control: no-cache" header is included # no-store - enables compression if the "Cache-Control: no-store" header is included # private - enables compression if the "Cache-Control: private" header is included # no_last_modified - enables compression if the "Last-Modified" header is not included # no_etag - enables compression if the "ETag" header is not included # auth - enables compression if the "Authorization" header is included # any - enables compression unconditionally gzip_proxied expired no-cache no-store private auth;
    # For CDN and proxy servers, for the same URL, compressed and uncompressed copies can be returned based on the header information gzip_vary on
}

Condition Monitoring

server {
	location /NginxStatus {
		stub_status on;
		access_log off;
	}
}

Plugin Installation

./configure --prefix=... --with-http_stub_status _module

The above is a detailed summary of how to optimize Nginx performance under high concurrency. For more information on Nginx performance optimization under high concurrency, please pay attention to other related articles on 123WORDPRESS.COM!