Nginx limit_zone and limit_req_zone Test report

Nginx has two restricted connection modules: limit_zone and limie_req_zone. Both of them can restrict connections. But what is the difference?
The following is an explanation on the nginx official website.
Limit_req_zone
Limit frequency of connections from a client.
This module allows you to limit the number of requests for a given session, or as a special case, with one address.
Restriction done using leaky bucket.

Limit_zone
Limit simultaneous connections from a client.
This module makes it possible to limit the number of simultaneous connections for the assigned session or as a special case, from one address.

Literally speaking, the lit_req_zone function limits the connection frequency by using the token bucket principle (this module allows you to limit the number of requests specified by a single address for a session or special needs)
The limit_zone function limits the number of concurrent connections of a client. (This module can limit the number of concurrent connections for a specified session or in special cases)
One is to limit concurrent connections and the other is to limit the connection frequency. On the surface, it seems that there is no difference, so let's take a look at the actual results ~~~
Add these two parameters to my testing machine. Below are some of my configuration files.
Http {
Limit_zone one $ binary_remote_addr 10 m;
# Limit_req_zone $ binary_remote_addr zone = req_one: 10 m rate = 1r/s;
Server
{
......
Limit_conn one 1;
# Limit_req zone = req_one burst = 120;
......
}
}

Description: limit_zone one $ binary_remote_addr 10 m;
Here, one declares the name of a limit_zone, $ binary_remote_addr is a variable that replaces $ remore_addr, and 10 m is the space for storing session status.
Limit_conn one 1, limit the number of concurrent connections on the client to 1
Test the limit_zone module first.
I am looking for a machine to test the command format with AB:
AB-c 100-t 10 http: // 192.168.6.26/test. php
The content of test. php is phpinfo.
Look at the access in the log

It seems that it may not be possible to limit 1 second for one concurrent connection. (Some netizens told me that this is because the file being tested is too small to do so. Please test it if you have time ), from the log, it can be seen that except for a few 200, the other is basically 503, and most concurrent access is 503.
I ran more with AB for a while and found another situation.

It seems that the effect will also change with the increase in the number, but it does not completely achieve the effect described in the module description.
Check the current number of tcp connections
# Netstat-n | awk '/^ tcp/{++ S [$ NF]} END {for (a in S) print a, S [a]}'
TIME_WAIT 29
FIN_WAIT1 152
FIN_WAIT2 2
ESTABLISHED 26
SYN_RECV 16

In this test, the configuration file of limit_req_zone is slightly changed.
Http {
# Limit_zone one $ binary_remote_addr 10 m;
Limit_req_zone $ binary_remote_addr zone = req_one: 10 m rate = 1r/s;
Server
{
......
# Limit_conn one 1;
Limit_req zone = req_one burst = 120;
......
}
}
Restart nginx
Simply put, rate = 1r/s means that each address can only request once per second. That is to say, according to the token bucket principle, burst = 120 has a total of 120 tokens, and only one token is added per second,
After sending the 120 token, the system returns the 503
Test
AB-c 100-t 10 http: // 192.168.6.26/test. php
Check the access logs at this time.

It is indeed a request every second. How long will it be tested? Increase the time from 10 seconds to 30 seconds

 

At this time, it should be 120, which is not enough. There are many 503 Cases, and there are two other cases. Please refer to the figure.

This situation seems to have timed out because some requests in the queue fail to respond, but I'm not sure if this is the case.

The client cannot wait until it is disconnected, and 499 is returned.
Check the current number of tcp connections
Netstat-n | awk '/^ tcp/{++ S [$ NF]} END {for (a in S) print a, S [a]}'
TIME_WAIT 51
FIN_WAIT1 5
ESTABLISHED 155
SYN_RECV 12

Although this will allow nginx to process only one request in one second, there will still be many waiting for processing in the queue, which will also occupy a lot of tcp connections, we can see from the results of the above command.
What if so?
Limit_req zone = req_one burst = 120 nodelay;
After nodelay is added, 503 is returned for requests that exceed the burst size,

It also processes one request per second, but the extra requests do not wait for processing as they have just been, but directly return 503.
Current tcp Connection
# Netstat-n | awk '/^ tcp/{++ S [$ NF]} END {for (a in S) print a, S [a]}'
TIME_WAIT 30
FIN_WAIT1 15
SYN_SENT 7
FIN_WAIT2 1
ESTABLISHED 40
SYN_RECV 37
The number of connections is less than the above.
Through this test, I found that neither of these modules can be absolutely limited, but it has indeed played a major role in reducing concurrency and limiting connections, in the production environment, the specific use or need to be used together depends on their own needs.
The test is here. If there is something wrong in the article, please correct it in time. Thank you.
This article is from the "story sky" blog