0

I'm working in a Bitnami installation of Apache2 and PHP (5.6) and we have trouble with a script that's taking longer than 60 seconds to complete.

This script in question is failing after 60 seconds, sending a 504 error.

I already checked all other possibilities, but it keeps going back to the execution time.

if(round($mem_usage/1048576,2) > 36)
{
    echo "exceded 36mb, aborting<br>";
    echo "element: ".$fila." of ".mysql_num_rows($result)."<br>";
    echo "memory usage: ".round($mem_usage/1048576,2)."M <br>";
    echo "memory limit: ".ini_get('memory_limit')." <br>";
    echo "max_execution_time: ".ini_get('max_execution_time')."<br>";
    $time_end = microtime(true);
    $time = $time_end - $time_start;
    echo "time elapsed: ".ceil($time)." seconds";

    exit();
}

Memory values are always under the normal range (we increased the memory limit just in case), but the script failed to print this message whenever time elapsed 60 seconds, so we discarded Memory Usage.

I've searching a lot in StackExchange questions, and I compiled a list of common answer to this problem:

  • max_execution_time

We tried increasing it to 300 however, this had no effect. PHP seems to ignore this value, already checked php_info() just in case it wasn't setting, but it is.

  • Memory Limit

See above, RAM usage keep within normal range. Not the cause of the crashes.

  • Doing a try{}catch(){}

The scripts halts, and doesn't execute the code inside the catch block.

  • Checking error logs

PHP is NOT throwing anything to the error logs, it just terminates the script abruptly and without any output, we already checked the log options in php.ini

  • set_time_limit()

This method is returning FALSE, according to the documentation it means it's failing to set a new time limit, which safe mode is a common cause of this happening, which leads us to the next step

  • Safe Mode

This is PHP5.6, according to the documentation.

This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.
  • max_input_time

We set it to 300, no effect.

  • default_socket_timeout

Ditto

  • Checked .htaccess for related configurations

Done, and we didn't find anything.

  • Setting timeout in Apache configuration

We didn't have a Timeout option in our Apache configuration, and when added, it had no effect.

  • I'm getting more suggestions in answers, so I'm adding them here.

This isn't possible for some PHP scripts, but have you tried running the script from the command line rather than via HTTP request? This would rule out if there's an Apache or PHP-FPM config screwing things up.

This script can't be run in CLI, but running a dummy script causes to execute indefinitely, so CLI doesn't halt the execution.

Do you have anything set for max_execution_time or request_terminate_timeout in your PHP-FPM config?

request_terminate_timeout is set to 300, no effect. php_admin_value[max_execution_time] is set to 300, no effect. (this one has to be set this way, according to documentation)

Do you have anything set for LimitRequestBody (or any other limits for that matter) in your Apache config?

Not set anywhere, and no other related limits in Apache configuration.

Are you performing a file upload when this happens? If so, have you checked upload_max_filesize and post_max_size in your PHP config?

No file upload is taking place in this request, so these limits are irrelevant in this specific situation.

It doesn't make sense that you would be getting different responses based on the browser, unless you are doing some kind of browser detection in your PHP and having your application behave differently based on this. If you aren't doing this, and you can consistently confirm this correlation, one thing you could do is see if the two different browsers are for some reason sending different requests.

Apparently it's how Firefox displays the error, using the Developer Console in Network shows a 504 same like in Chrome (My mistake when I asked the question as I put 503 by accident.)

have you tried ignore_user_abort(true)

Just enabled ignore_user_abort (via PHP-FPM settings). And it had no effect.

and/or attempting to capture some diagnostics via register_shutdown_function()?

Attempting to register the shutdown function has no effect, since the code block is never executed.


As a final note, this server has PHP-FPM, and that's where we are settings the PHP configurations, however nothing we do has any effect and the script in question is still terminating after 60 seconds.

Any help with this issue will be appreciated.

  • Are you hitting the apache server directly or through a load balancer or proxy? – Jason Floyd May 9 at 18:05
  • @JasonFloyd We were using AWS Load Balancer, and we managed to fix this problem thanks to your comment. Thank you. – Gabriel I. May 9 at 19:06
  • Glad to hear it helped! – Jason Floyd May 13 at 19:43
1

Some additional things to check:

  • This isn't possible for some PHP scripts, but have you tried running the script from the command line rather than via HTTP request? This would rule out if there's an Apache or PHP-FPM config screwing things up.
  • Do you have anything set for max_execution_time or request_terminate_timeout in your PHP-FPM config?
  • Do you have anything set for LimitRequestBody (or any other limits for that matter) in your Apache config?
  • Are you performing a file upload when this happens? If so, have you checked upload_max_filesize and post_max_size in your PHP config?
  • It doesn't make sense that you would be getting different responses based on the browser, unless you are doing some kind of browser detection in your PHP and having your application behave differently based on this. If you aren't doing this, and you can consistently confirm this correlation, one thing you could do is see if the two different browsers are for some reason sending different requests.
  • Hello and thanks for the time. I edited the OP adding the steps you suggested. – Gabriel I. May 9 at 16:24
1

Are you hitting the apache server directly or through a load balancer or proxy?

This comment in the OP made me realize we were using AWS Load Balancer. Upon checking the documentation we saw it has a default idle timeout of 60 seconds.

Increasing this limit allowed the script to finish gracefully.

0

In addition to the excellent suggestions from Brad, have you tried ignore_user_abort(true) and/or attempting to capture some diagnostics via register_shutdown_function()?

  • Hello and thanks for the suggestions, unfortunately they had no effect. I updated the OP with more details. – Gabriel I. May 9 at 16:42
  • ...and are you testing the scripts via http://localhost or from a more remote location? – symcbean May 9 at 18:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.