Nginx504GatewayTime-out troubleshooting _ PHP Tutorial

Troubleshooting nginx504GatewayTime-out errors. A nginx504GatewayTime-out error troubleshooting, resolution records, after repeated checks, found that the cause of this problem is that php curl does not set the timeout time, to solve this problem, you only need to set the timeout Time for an nginx 504 Gateway Time-out error and resolution record. after repeated checks, it is found that the cause of this problem is that php curl does not set the timeout Time, to solve this problem, you only need to set the timeout time or modify the nginx configuration.

Record an inexplicable failure to respond to the website for troubleshooting. Previously, the website used nginx as the proxy backend apache to run php to provide services. Apache is often unable to respond to service failures from Time to Time, and then nginx appears "504 Gateway Time-out"
You can't see anything when you view the error log, because it is an apache bug (not actually, the cause is described below ).
If you are older, you may be reluctant to make changes. if you are willing to remain unchanged, you can use monitoring tools to restart apache every time you receive an alarm. Finally, one day I got bored. isn't it just processing php? I don't need to use the apache general line. in anger, I use the source to install php-fpm and transfer it to php-fpm to run php. Installing php is not troublesome, and the installation from the source is still smooth. The only thing that needs to be done is to set the php worker workflow log to output the php error log.

After everything is ready, replace the original proxy_pass with fastcgipass.
Upstream apachephp {

Server www.jb51.net: 8080; # Apache1
}
....
Proxy_pass http: // apachephp;

Replace
Upstream php {

Server 127.0.0.1: 9000;
}
...
Fastcgi_pass php;

You can migrate the php running on apache to php-fpm.
In this way, you can rest assured that the migration is complete, but if you do not analyze the root cause of the problem. The problem still persists. The next day, nginx reported the gateway timeout of 504. This time there is nothing to do with apache. apache has finally been clear of the relationship.
Check the nginx error log on nginx and php-fpm.
[Error] 6695 #0: * 168438 upstream timed out (110: Connection timed out) while reading response header from upstream,

...
Request: "GET/kd/open. php? Company = chinapost & number = PA24977020344 HTTP/1.1 ", upstream:" fastcgi: // 127.0.0.1: 9000 ", host:" www.jb51.net"

The nginx suspect is basically ruled out here. nginx is waiting for php to process "GET/kd/open. php? Company = chinapost & number = PA24977020344 HTTP/1.1 "times out and exits.
Restart php-fpm immediately. if the problem persists, the website can be accessed.
When I access this page again, I still have no response, but it is normal to visit other pages at the same time. after the page is refreshed several times, the entire website is in bad gateway timeout.
The problem is reduced to the php script.
Netstat-napo | grep "php5-fpm" | wc-l

Check that the php workflow has reached the upper limit of 10 in the configuration file. the feeling is that everyone is stuck by the open. php script.
What is this script? This script collects the parcel information and uses php_curl.
If the execution time of the PHP script exceeds the configuration item max_execution_time in php. ini, the script will exit forcibly if it does not return the result.
Check that the max_execution_time configuration in php. ini is correct and the value is 30.
The omnipotent google comes in handy. after google continues to get the following sentence:
The set_time_limit () function and the configuration command max_execution_time only affect the execution time of the script. The maximum time for executing any script that occurs in a system call, stream operation, or database operation that uses system () is not included when the script has been run. Www.jbxue.com
That is to say, if other operations are executed in the script, the time is not counted in the script running time. if you do not set the time-out, php will always wait for the call result.
Check the open. php source file and check that no curl timeout is set.
Add the following two lines and refresh again. then the problem is solved.
Curl_setopt ($ ch, CURLOPT_CONNECTTIMEOUT, 10); // timeout on connect

Curl_setopt ($ ch, CURLOPT_TIMEOUT, 10); // timeout on response
Of course, in addition to this method, php-fpm also provides parameters for us to forcibly kill a process with no results for a long time, but this parameter is not enabled by default.
In the configuration file of php-fpm, you can set a parameter request_terminate_timeout to specify the request termination timeout. if the request execution time exceeds this time, it will be killed.
At the same time, it also has a parameter request_slowlog_timeout, which is used to record slow request logs.
You can use this code to run php on the command line.

$ Real_execution_time_limit = 60; // time limit if (pcntl_fork ()) {// some long time code which shocould be // terminated after $ real_execution_time_limit seconds passed if it's not // finished by that time} else {sleep ($ real_execution_time_limit ); posix_kill (posix_getppid (), SIGKILL );}

Timeout 504 Gateway Time-out error troubleshooting and resolution records. after repeated checks, it is found that the cause of this problem is that php curl does not set the timeout Time. to solve this problem, you only need to set the timeout Time...