The server Load balancer described in this article is used to balance client requests among multiple nginx processes. Note the difference between Server Load balancer and client requests on multiple backend servers.
The problem of Server Load balancer occurs in nginx. When a connection is established, the Server Load balancer problem is designed. When multiple sub-processes compete for a new connection event, only one worker sub-process will successfully establish a connection, and then it will continue to process the connection until the connection is closed. In this case, some sub-processes establish and process most of the connections, while some sub-processes only process a few connections. This is not good for applications in multi-core CPU architecture. Because sub-processes should be equal to each other, and each sub-process should try to exclusively occupy one CPU core. Load imbalance between sub-processes will definitely affect the performance of the entire service. How to solve the Server Load balancer problem is the same as how to solve the group problem. Only when the accept_mutex lock is enabled can the load balancing between sub-processes be realized. At the same time, the post event mechanism is also the key to solving the load balancing problem. Refer to the previous article http://blog.csdn.net/xiajun07061225/article/details/9260535. When the ngx_event_accept method creates a new connection, a global variable ngx_accept_disabled is initialized. It is the key threshold for implementing the load balancing mechanism. Its definition (/src/event/ngx_event.c): ngx_int_t ngx_accept_disabled; Initialization (Sr/event/ngx_event_accept.c) is in the ngx_event_accept function: ngx_accept_disabled = ngx_cycle-> connection_n/8-ngx_cycle-> free_connection_n; in this way, it is actually a negative value when nginx is started:-7/8 * ngx_cycle-> connection_n.
The core code for Load Balancing Based on this value is in the function ngx_process_events_and_timers (src/event/ngx. event. c): // Server Load balancer Processing
If (ngx_accept_disabled> 0) {ngx_accept_disabled --;} else {// call the authorization method and try to obtain the accept lock if (ngx_trylock_accept_mutex (cycle) = ngx_error) {return ;}
Explanation: When ngx_accept_disabled is a negative number, the Server Load balancer operation is not triggered. Normally, the accept lock is obtained and new connections are processed. When ngx_accept_disabled is a positive number, the Server Load balancer operation is triggered. Nginx does not process New Connection events at this time. Instead, it only deletes the variable ngx_accept_disabled by one. This means that the load will definitely decrease after a round of event processing, so you need to adjust this value accordingly.
That is, it is triggered only when the number of connections in use exceeds 7/8 of the total number of connections. A larger value indicates a heavier load. Each time process_events is called, only one ngx_accept_disabled is subtracted until ngx_accept_disabled is reduced to 0, that is, the number of connections used is reduced to 7/8 of the total number of connections. This reduces the chance for the Worker Process to process new connections. In this way, other idle worker processes have the opportunity to process more new connections to achieve a balanced effect on the entire web server.
Nginx sets the accept_mutex configuration item to accept_mutex on by default. Nginx http://www.cppblog.com/converse/archive/2009/12/08/102816.html references
