Improve website performance: Nginx five efficient load balancing strategies

Foreword

This article is included in the csdn column “Linux Basic Skills-System Service Combat”, which I am Mu Fengxiaoyue. The series about nginx will be summarized later, follow me, and learn and grow together.

In the process of writing this column, we have joined forces with several bigwigs from csdn, and are currently sorting out and updating the catalog, trying to let everyone learn some real things, put the theories learned into practice, and help you improve yourself faster.

The most difficult part of learning technology is actually the process of finding the best information. This time, I joined with several cloud-native bloggers from csdn to create an easy-to-learn, easy-to-understand, and landing architecture and a cloud-native column.

Article directory

  • foreword
  • 1. Key knowledge review
    • 1.1 Nginx kernel and module division
    • 1.2 Nginx module processing flow
    • 1.3 The role of nginx load balancing
  • 2. Load balancing algorithm
    • 2.1 Theoretical review on load balancing
    • 2.2 Algorithms commonly used in nginx
      • 1. Polling (default method)
      • 2. Weight strategy (weight weighted round robin)
      • 3. ip_hash
      • 4. fair
      • 5. url_hash
      • 6. least_conn
  • Summarize

1. Key knowledge review

1.1 Nginx kernel and module division

  1. kernel

Its design is very small and simple, and the job done is also very simple. Only by looking up the configuration file, the client request is mapped to a location block (location is an instruction in the nginx configuration, and the use case URL matches), and each instruction configured in this location will start different modules to complete the corresponding Work.

  1. Structurally divided:
  • Core modules: HTTP module, EVENT module and MAIL module. Basic modules: HTTP Access module, HTTP FastCGI module, HTTP
  • Proxy module and HTTP Rewrite module. Third-party module: HTTP Upstream Request
  • Hash module, Notice module and HTTP Access Key module.

Generally, we just need to remember the name of the module, so that we have a bottom line.

  1. Functionally divided
  • Core (core module): Build nginx basic services and manage other modules.
  • Handlers (processor module): This type of module directly processes requests, and performs operations such as outputting content and modifying headers information. Handlers generally only has one processor module.
  • Filters (filter module): This type of module mainly modifies the content output by other processor modules, and is finally output by Nginx.
  • Proxies (proxy module): This type of module is a module such as Nginx’s HTTP Upstream, these modules are mainly related to some backend services
    For example, interact with FastCGI to realize functions such as service proxy and load balancing.

1.2 Nginx module processing flow

  1. An HTTP request is received.
  2. Nginx selects an appropriate processing module (Handlers) based on the location in the configuration file.
  3. The Handlers module needs to reverse proxy the request to the backend server, so it needs to become another type of module: load-balancers (load balancing module)
  4. The configuration of the load balancing module has a set of backend servers, and when an HTTP request comes in, it decides which server should get the request.
  5. After processing is complete, filters (filtering modules) will be called. Each request can be compressed into chunks and passed through multiple filters in turn. Their execution order is determined at compile time. The filtering module chain efficiently sends response information to the client in a pipelined manner. Each filters will not wait for the previous filters to complete, just like a pipeline.
  6. Finally, the response is sent to the client.

Nginx itself does very little work. When it receives an HTTP request, it simply maps the request to a location block by looking up the configuration file. The command will start different modules to complete the work, so the module can be regarded as the real labor worker of Nginx.

1.3 The role of nginx load balancing

  • Solve the high concurrency pressure of the server and improve the processing performance of the application;
  • Provide failover to achieve high availability;
  • Enhance the scalability of the website by adding or reducing the number of servers;
  • Filtering on the load balancer can improve the security of the system.

2. Load balancing algorithm

2.1 A theoretical review of load balancing

Load balancing means that Nginx evenly distributes requests to upstream application servers, so that even if a certain server goes down, it will not affect the processing of requests, or when the application server cannot handle it, it can expand at any time.

Nginx distributes the client’s request to the back-end server of the deployment project, such as tomcat, according to the corresponding rules. The corresponding rules here are actually specified in the configuration file: pass_proxy directive and upstream directive.

Static load balancing algorithm: mainly includes round robin algorithm, weighted round robin algorithm based on ratio or weighted round robin algorithm based on priority;
Algorithms for dynamic load balancing: mainly include least connection optimization algorithm based on task volume, fastest response priority algorithm based on performance, prediction algorithm and dynamic performance allocation algorithm, etc.;

Generally, dynamic load balancing algorithms are more suitable for complex network environments.

Load balancing is divided based on the OSI seven-layer model:

OSI seven-layer model:

  1. Physical Layer: Bit Stream Transmission
  2. Data link layer: controls the communication between the network layer and the physical layer;
  3. Network layer: IP addressing and routing;
  4. Transport layer: establish, maintain, and manage end-to-end connections, the common ones are TCP/UDP;
  5. Session layer: establish, maintain, and manage session connections;
  6. Presentation layer: perform operations such as formatting, encoding, encrypting, and compressing data;
  7. Application layer: provides network services for applications;
  • The four-layer load is in the transport layer, based on IP + port load balancing, the common ones are:
Hardware: F5, BIG-IP, Radware, etc.;
 Software: LVS, Nginx, Hayproxy, etc.

nginx adds a stream module, which is used to realize the forwarding, proxy, load balancing, etc. of the four-layer protocol.

The usage of the stream module is similar to that of http, allowing us to configure a set of monitoring protocols such as TCP or UDP, and then forward our requests through proxy_pass, and add multiple back-end services through upstream to achieve load balancing;

To use the stream mode, you need to add --with-stream when compiling.

  • Layer-7 load balancing is mainly at the application layer, mainly based on virtual URL or host IP load balancing:
The way to achieve seven-layer load balancing:
    Software: Nginx, Hayproxy, etc.

2.2 Algorithms commonly used in nginx

The upstream of Nginx supports the following six distribution algorithms, namely:

Algorithm name Description
Polling default method
weight weight method
ip_hash According to the ip allocation method
least_conn Based on the least connection method
url_hash According to URL distribution method
fair According to response time method

1. Polling (default method)

Round robin is the default load balancing strategy of the upstream module, and each request will be assigned to different backend servers one by one in chronological order. Polling requires no additional configuration.

upstream mufengserver{<!-- -->
        server 192.168.1.41:8080;
        server 192.168.1.42:8081;
    }
server {<!-- -->
listen 80;
server_name localhost;
location / {<!-- -->
# mufengserver is the name of the server group
proxy_pass http://mufengserver/;
}
}

2. Weight strategy (weight weighted round robin)

The higher the weight parameter behind weightt=number, the more tasks there will be. The larger the weight number, the greater the probability of being assigned to the request. The default is 1;
It is used when the server performance is unbalanced, and it is mainly adjusted for different back-end server hardware configurations in the actual working environment. All this strategy is more suitable for situations where the server hardware configurations are quite different.

For example, if your server has both 4C8G and 8C16G servers, then you can set some weights on the servers at this time, so that better performance can bear more requests.

upstream mufengserver{<!-- -->
        server 192.168.1.41:9001 weight=5;
        server 192.168.1.42:9002 weight=1;
    }
server {<!-- -->
listen 8080;
server_name localhost;
\t\t
location / {<!-- -->
# mufengserver is the name of the server group
proxy_pass http:/mufengserver/;
}
}

3. ip_hash

When performing load balancing on multiple dynamic application servers at the backend, the ip_hash command can locate the request of a certain client IP to the same backend server through the hash algorithm;
When a user from a certain IP logs in on the back-end web server A, and then accesses other URLs of the site, it can be guaranteed that the user accesses the back-end web server A;

 # proxy server
# Set server group
upstream mufengserver{<!-- -->
        ip_hash;
server localhost:9001;
server localhost:9002;
server localhost:9003;
}
server {<!-- -->
listen 8080;
server_name localhost;
\t\t
location / {<!-- -->
# backend is the name of the server group
proxy_pass http://mufengserver/;
}
}

Note: Using the ip_hash command cannot guarantee the load balance of the back-end servers, which may cause some back-end servers to receive more requests, and some back-end servers to accept fewer requests, and methods such as setting back-end server weights will not work.

4. Fair

fair mainly assigns tasks according to the access time, and intelligently performs load balancing according to the size of the page and the length of loading time;
To use third-party module fair must install upstream_fair module;

upstream myserver{<!-- -->
        server 192.168.137.13:8082;
        server 192.168.137.13:8081;
        fair;
    }
server {<!-- -->
listen 8080;
server_name localhost;
\t\t
location / {<!-- -->
# mufengserver is the name of the server group
proxy_pass http://mufengserver/;
}
}

5. url_hash

The third-party plug-in needs to install Nginx’s hash package, and allocate requests according to the hash result of the accessed URL, so that each URL is directed to the same back-end server, and it must be used in conjunction with cache hits.
Sometimes multiple requests for the same resource may arrive at different servers, resulting in unnecessary multiple downloads, low cache hit rate, and waste of resource time, but using url_hash, you can So that the same url (that is, the same resource request) will arrive at the same server. Once the resource is cached and the request is received again, it can be read from the cache.

 # proxy server
# Set server group
upstream mufengserver {<!-- -->
        hash $request_uri;
server localhost:9001;
server localhost:9002;
server localhost:9003;
}
server {<!-- -->
listen 8080;
server_name localhost;
\t\t
location / {<!-- -->
# mufengserver is the name of the server group
proxy_pass http://mufengserver;
}
}

6. least_conn

least_conn: The least connection, forward the request to the backend server with fewer connections.

The polling algorithm is to forward the requests to each backend evenly, so that their loads are roughly the same; however, some requests take a long time, which will lead to a higher load on the backend where they are located. In this case, least_conn can achieve better load balancing effect.

This method is suitable for situations where the server is overloaded due to different request processing times.

upstream mufengserver{<!-- -->
        least_conn;
server localhost:9001;
server localhost:9002;
server localhost:9003;
}
server {<!-- -->
listen 8080;
server_name localhost;
\t\t
location / {<!-- -->
# mufengserver is the name of the server group
proxy_pass http://mufengserver/;
}
}

Summary

Well, this is all the content I want to share with you today, see you next time!
This article was originally created by Mu Feng Xiaoyue, first published on the CSDN blog, blog homepage: mufeng.blog.csdn.net
Learning is like sailing against the current. If you don’t advance, you will retreat. Let’s work hard together!
If you like it, remember to like and collect it