Hi,
I'm still having some pretty serious issues with sites that I'm testing with the new Plesk custom versions of PHP (I'm just using 5.6).
Any site that I enable 5.6 on starts getting the "Premature end of script headers" errors in the error_log, and I also get occasional Server 500 errors, mostly when using the WordPress Admin (as opposed to on the front-end of the site)
If I switch back to PHP 5.4 the problems stop.
I've been searching high and low, and have tried all sorts of things, but I'm getting nowhere, can anyone help?
Firstly, I'm using PHP memory limit of 128MB -- is that too low for PHP 5.6? Could this be the problem?
Other changes I've made to try and resolve this:
In /etc/httpd/conf.d/fcgid.conf
Increased fcgidIOTimeout to 300 -- hasn't helped.
In /etc/nginx/nginx.conf
Increased keepalive_timeout to 300 -- hasn't helped.
I also created a file /etc/nginx/conf.d/timeout.conf with the following:
proxy_read_timeout 300;
proxy_connect_timeout 300;
fastcgi_read_timeout 300;
None of this has helped either.
Something I've found that does sound similar to what I am experiencing is on the Apache docs page for fcgi: http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#examples
In particular, the section "Special PHP considerations"
In case it helps anyone else experiencing these issues, here's a few links I've come across and have been referring to:
Thanks.
I'm still having some pretty serious issues with sites that I'm testing with the new Plesk custom versions of PHP (I'm just using 5.6).
Any site that I enable 5.6 on starts getting the "Premature end of script headers" errors in the error_log, and I also get occasional Server 500 errors, mostly when using the WordPress Admin (as opposed to on the front-end of the site)
If I switch back to PHP 5.4 the problems stop.
I've been searching high and low, and have tried all sorts of things, but I'm getting nowhere, can anyone help?
Firstly, I'm using PHP memory limit of 128MB -- is that too low for PHP 5.6? Could this be the problem?
Other changes I've made to try and resolve this:
In /etc/httpd/conf.d/fcgid.conf
Increased fcgidIOTimeout to 300 -- hasn't helped.
In /etc/nginx/nginx.conf
Increased keepalive_timeout to 300 -- hasn't helped.
I also created a file /etc/nginx/conf.d/timeout.conf with the following:
proxy_read_timeout 300;
proxy_connect_timeout 300;
fastcgi_read_timeout 300;
None of this has helped either.
Something I've found that does sound similar to what I am experiencing is on the Apache docs page for fcgi: http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#examples
In particular, the section "Special PHP considerations"
By default, PHP FastCGI processes exit after handling 500 requests, and they may exit after this module has already connected to the application and sent the next request. When that occurs, an error will be logged and 500 Internal Server Error will be returned to the client. This PHP behavior can be disabled by setting PHP_FCGI_MAX_REQUESTS to 0, but that can be a problem if the PHP application leaks resources. Alternatively, PHP_FCGI_MAX_REQUESTS can be set to a much higher value than the default to reduce the frequency of this problem. FcgidMaxRequestsPerProcess can be set to a value less than or equal to PHP_FCGI_MAX_REQUESTS to resolve the problem.
PHP child process management (PHP_FCGI_CHILDREN) should always be disabled with mod_fcgid, which will only route one request at a time to application processes it has spawned; thus, any child processes created by PHP will not be used effectively. (Additionally, the PHP child processes may not be terminated properly.) By default, and with the environment variable setting PHP_FCGI_CHILDREN=0, PHP child process management is disabled.
The popular APC opcode cache for PHP cannot share a cache between PHP FastCGI processes unless PHP manages the child processes. Thus, the effectiveness of the cache is limited with mod_fcgid; concurrent PHP requests will use different opcode caches.
I cannot find the setting "PHP_FCGI_MAX_REQUESTS" -- where do I adjust this?PHP child process management (PHP_FCGI_CHILDREN) should always be disabled with mod_fcgid, which will only route one request at a time to application processes it has spawned; thus, any child processes created by PHP will not be used effectively. (Additionally, the PHP child processes may not be terminated properly.) By default, and with the environment variable setting PHP_FCGI_CHILDREN=0, PHP child process management is disabled.
The popular APC opcode cache for PHP cannot share a cache between PHP FastCGI processes unless PHP manages the child processes. Thus, the effectiveness of the cache is limited with mod_fcgid; concurrent PHP requests will use different opcode caches.
In case it helps anyone else experiencing these issues, here's a few links I've come across and have been referring to:
- http://expressionengine.stackexchan...in-45-seconds-premature-end-of-script-headers
- http://stackoverflow.com/questions/4336757/500-server-error-premature-end-of-script-headers
- http://stackoverflow.com/questions/...-fcgid-error-reading-data-from-fastcgi-server
- https://shiftlock.wordpress.com/2013/06/29/troubleshooting-error-reading-data-from-fastcgi-server/
- http://www.curvve.com/blog/guides/2012/apache-turning-on-plesk-server/
Thanks.