As you open this article, you are probably familiar with nginx’s basic logging parameters, and the request_time parameter is extremely familiar. Not surprisingly, request response time, which should be all you know about it at this point. Nginx has multiple log time variables, including request_time, that can be configured to improve troubleshooting efficiency, especially for timeout problems. Let’s begin.
Note: All variables mentioned in this article are defined as variables in ngx_HTTP_upstream_module, if any. If you need to use parameters in other modules, seeNginx official documentation
First, the official definition
(The following English definitions are taken from the official documentation of nGINx, last updated on July 11)
$request_time
request processing time in seconds with a milliseconds resolution; time elapsed between the first bytes were read from the client and the log write after the last bytes were sent to the client
Nginx service, the time elapsed between the first byte fetched by the requesting client and the last byte returned to the client. The unit is second.
$upstream_connect_time
Keeps time spent on establishing a connection with the upstream server (1.9.1); the time is kept in seconds with millisecond resolution. In case of SSL, includes time spent on handshake. Times of several connections are separated by commas and colons like addresses in the $upstream_addr variable.
Nginx service, the time elapsed to establish a connection with the upstream service. The unit is second. In the case of SSL, the time spent during the handshake is also recorded. The time of multiple requests, separated by commas and colons, in the format of the $upstream_ADDR variable.
$upstream_header_time
Keeps time spent on receiving the response header from the upstream server (1.7.10); the time is kept in seconds with millisecond resolution. Times of several responses are separated by commas and colons like addresses in the $upstream_addr variable.
Nginx service, the amount of time it takes to receive a response header from an upstream service. The unit is second. Time to respond to multiple requests, separated by commas and colons, in the format of the $upstream_ADDR variable.
$upstream_response_time
keeps time spent on receiving the response from the upstream server; the time is kept in seconds with millisecond resolution. Times of several responses are separated by commas and colons like addresses in the $upstream_addr variable.
Nginx service, the amount of time it takes to receive a response from an upstream service. The unit is second. Time to respond to multiple requests, separated by commas and colons, in the format of the $upstream_ADDR variable.
Define the parsing
Personally, I feel that the official definition is not very friendly. Firstly, it does not explain the starting point and ending point of calculating time, and secondly, it does not explain the relationship between different time concepts, which is easy to confuse people. Therefore, the author combined with personal understanding, the definition of a little explanation, convenient for everyone to understand, if there is a misunderstanding of the place, also hope to point out.
$request_time
(The official definition of this variable is accurate and will not be used elsewhere.)
Nginx service, the time elapsed from the first byte fetched by the requesting client to the last byte returned to the client after the log was written to the file. The unit is second.
$upstream_connect_time
Nginx service, the time elapsed between establishing a connection with the upstream service and establishing a successful connection. The unit is second.
$upstream_header_time
The elapsed time between the time the nginx service establishes a connection with the upstream service and the time it receives the first byte of the response return header. The unit is second.
$upstream_response_time
The elapsed time between the connection with the upstream service and the last byte returned after receiving the response from the nginx service. The unit is second.
From the graph above, we can easily draw the following conclusion
- The actual runtime of the program = $upstream_header_time – $upstream_connect_time
- $request_time contains the data return time
- $request_time contains the log printing time
So the question is, what is the use of these conclusions?
Scenario, for example,
$request_time ($upstream_header_time); $upstream_response_time ($upstream_response_time)
Analysis: According to the above conclusion, this time reflects that the upstream program is executing slowly, and it is necessary to check the log related to the execution of the program
$request_time = $upstream_response_time = $upstream_response_time = $upstream_response_time = $upstream_response_time
$upstream_response_time = $upstream_response_time = $upstream_response_time = $upstream_response_time = $upstream_response_time = $upstream_response_time = $upstream_response_time = $upstream_response_time = $upstream_response_time The slow data return can be analyzed by packet capture, which is usually caused by the user’s network. If log printing is blocked, there may be a problem with the MACHINE I/O, which is easy to find. There may also be a problem with nginx configuration parameters, which may cause a delayed shutdown.
Brave teenager, believe these variables can help you a lot, Hope you enjoy it!
I’ll leave you with a quick question. Why are all nginx calls “upstream” and not “downstream” or something else? Is the design counterintuitive?