Fatal error: Maximum execution time of 30 seconds exceeded & timeout problems (PHP debugging)

The error message above in the title line indicates that you have some code that takes too long to run in your php file. There is a sanity check that keeps track of the time you spend on a page, and the timer times-out you will get the Maximum execution time exceeded message. The duration for this time-out value is set in the php.ini

maximum_execution_time = 30

You can reset this in your file to debug what is happening. Using

ini_set('max_execution_time', 300);

sets the maximum execution time to 300 seconds or 5 minutes.


You need to surround snippets of your code with some timestamp routines to figure out
which portion is taking up a long time.

$ts = microtime(true); 

   // code snippet to check timing of 

var_dump(microtime(true) - $ts);

If you are doing MySQL database queries, you can turn to the slow queries log to see if there are any SQL queries that are too complex and take a while to return (for e.g., a join with several large tables would slow down you query because of the large result set.

To enable the slow query log, start mysqld with the --log-slow-queries[=file_name]

The slow query log can be used to find queries that take a long time to execute and are therefore candidates for optimization. However, examining a long slow query log can become a difficult task. To make this easier, you can process a slow query log file using the mysqldumpslow command to summarize the queries that appear in the log.

Diagnosing slow PHP execution with Xdebug and KCachegrind

Profiling a PHP application can explain how much time the server spent in each function, each file, and each code path. It can also show you how many times a function or method was called, which is useful for diagnosing programming errors involving pointless looping. Xdebug generates cachegrind-compatible files which can also be used to create easy-to-understand graphs using KCachegrind.

The log file created by Xdebug can be small or large depending on what the application is doing. Also, it’s not really reader friendly. You’ll want to use programs like KCachegrind or Webgrind to view them. KCachegrind is a profile data visualization tool for KDE, which needs a Unix environment to run, whereas Webgrind is a web-based tool.

http://kcachegrind.sourceforge.net/html/Home.html
https://github.com/jokkedk/webgrind
https://github.com/ceefour/wincachegrind
http://ceefour.github.io/wincachegrind/

WinCacheGrind is a viewer for cachegrind.out files generated by xdebug 2. WinCacheGrind is functionally similar to KCacheGrind, only it is much simpler and runs on Windows.

As we have done in a previous PHP debugging tip, we need to enable certain Xdebug options in the php.ini file. Specifically those related to profiling.

xdebug.profiler_enable = 1
xdebug.profiler_output_name = xdebug.out.%t
xdebug.profiler_output_dir = /tmp
xdebug.profiler_enable_trigger = 1

xdebug.profiler_enable is used to enable profiling in Xdebug (off by default). xdebug.profiler_output_name is the filename of the profiler log (the %t specifier appends a timestamp to the filename. 
xdebug.profiler_output_dir stores the profiling output in the directory specified

Profiling degrades performance since the PHP engine.
xdebug.profiler_enable_trigger instructs Xdebug to perform profiling only when XDEBUG_PROFILE is passed as a GET or POST parameter.