Question

I have a php app that calls a class called Client. Every so often I get a sort of time out error. I thought it was SQL at first but it turns its pointing to the class itself.

Fatal error: Maximum execution time of 30 seconds exceeded in C:\Program Files (x86)\Apache Software Foundation\Apache2.2\htdocs\ClientPortal\classes\Connections.php on line 3

<?php
    session_start();
    class Connections { //line 3

Does anyone know what’s going on here?

thanks,

Billy

Answer 1

PHP scripts have a maximum time they’re allowed to execute for, as declared in the php.ini.

You can circumvent this if you really want by adding the following line:

ini_set('max_execution_time', 123456);

where 123456 is the number of seconds you want the limit to be.

You can also use the set_time_limit function, which I only just found out about and assume does the same thing. I’ve always just done the former though.

You can change it in the php.ini file, but you might be using your script to do a batch operation or something. You wouldn’t want a PHP script that is being accessed by an end user to sit there hanging for 30 seconds or more though, so you’re better off leaving it at the default or even turning it down in the php.ini file, and setting the max_execution_time on an as-needed basis.

As seengee points out in the comment below, you can set the max_execution_time to 0 to stop the error from ever happening, but seengee is right to say that at least for a web request, you really shouldn’t do this. For the php command line interpreter, this behaviour is the default though.

If you’re seeing this problem for things that are supposed to be used by end-users through a web request, you might have to do some profiling to work out the real cause. If you’re doing MySQL queries, start by turning on the slow query log. It’s particularly good at letting you know when you’ve forgotten an index, or if you’re doing something else inefficient.

You can also shove a few $s = microtime(true); yourstuff(); var_dump(microtime(true)-$s); things around to get a vague overview of which bits are slowing things down, just make sure you don’t leave any of them in afterwards!

If you’re still struggling to find the root cause, set xdebug up on your local machine and run the profiler. The extension is available as a precompiled windows binary (although there seems to be a confusing array of versions). You can inspect the results of running the profiler using wincachegrind.