My RSS » Planet PHP » February 7, 2010

Planet PHP

Troubleshoot – My PHP script is timing out

Posted: February 7th, 2010, 6:23pm MST by Venkat Raman Don

I hear a lot about the problem where web server (IIS) throws an error saying that PHP script has timed out in our forums. Let’s try to understand the reason behind this. I will be using a Windows 7 Enterprise machine (having IIS 7.5) to explain this but this should be applicable to Windows 2008/Windows Vista too. The same can be told true for Windows 2003/Windows XP with some difference like IIS stores FastCGI configuration in fcgiext.ini file rather than application meta-base. However the concept should be exactly similar.

Let me now summarize some of the IIS FastCGI settings and PHP INI configuration directive to ensure that everyone is on the same page and which are most important for this discussion.

Two important FastCGI settings:

ActivityTimeout – This is the number of seconds that the FastCGI handler waits for I/O activity from a process before it is terminated. At some place you will also find this as being documented as number of seconds PHP-CGI process can run without communicating to IIS.

RequestTimeout – This is the maximum amount of time in seconds that a FastCGI process is allowed to handle a request before it is terminated.

Important PHP INI directive for this discussion:

max_execution_time – This is the maximum time in seconds a script is allowed to run before it is terminated by parser. Details can be seen at [www.php.net] .

All the above three impacts your script execution time. Ideally you will have the value of RequestTimeout greater than or equal to ActivityTimeout. Well this is not a hard rule but going by meaning of these two timeouts it makes sense to do this. Assume you are uploading a file of size ‘X’ MB and it takes 500 second to upload it (assuming PHP is configured properly to allow upload of files and so the size of ‘X’ MB is also allowed) and you have below value for the two timeouts:

ActivityTimeout=501

RequestTimeout=400

This configuration will result into request timeout while uploading the file. The reason is that though an I/O operation (in this case file upload) is allowed for 501 seconds which is perfectly fine for this case, request time out is less than 501 (and is at 400) and so FastCGI will encounter a request timeout. Remember this will be done by the web server (IIS here) and not PHP. So setting the value of RequestTimeout higher than ActivityTimeout makes more sense.

However assume your max_execution_time is set to 300 seconds and you are running a PHP script which executes for time more than 300 seconds and FastCGI timeout settings are same as above. This time PHP will terminate itself.

This implies that (assuming you have RequestTimeout set to a value higher than ActivityTimeout) you script will run maximum for time in seconds which is configured for max_execution_time or RequestTimeout whichever is less.

This should help you configuring the PHP script to run for a longer period of time.

Some Frequently asked question

I am changing the fastcgi.ini file or php.ini file but settings are not getting effected on XP/2k3 or I am changing applicationhost.config or php.ini on a IIS7 machine and changes are not getting effected.

Please recycle the application pool or restart the server to make the FastCGI/PHP process read the new settings. If you are using latest FastCGI and you do not want to restart the application and want changes to be picked up on it’s own you can as well use the feature called ‘Monitor Changes to File’. Details about this can be found at [blogs.iis.net] for IIS7.5 and at [learn.iis.net] for IIS6.0. For information regarding if this feature is supported on your configuration or not please refer to blog post at "/>

Truncated by Planet PHP, read more at the original (another 7922 bytes)

Yesterday I finally had the time to setup my first continuous integration environment. Possible solutions for CI are phpUnderControl, Hudson or Arbit. Although phpUnderControl is the most wide-spread, but from I heard complex to setup/maintain, solution supposedly a hack and Arbit just in an early Alpha I decided to give Hudson a shoot. Another reason for this decision, I heard it has a simple plugin architecture and is easy to install and use. Additionally Hudson is easily integrated into Netbeans and Redmine, and I use both tools regularly in development.

My motivation to dive into CI is easily explained. I just never felt it was necessary to add a continuous integration enviroment to my projects, since I had one or two simple bash scripts that did the job. In general this is rather annoying, because they mostly only run PHPUnit and have to be done using a cronjob or manually, without any real process of notification. Additionally you have no way to navigate the test-results, code-coverage and no history of the last builds. For projects like Doctrine 2 we have the additional requirement to support 4 different database platforms, i.e. 4 different PHPUnit configurations. Currently that is solved by me using a Bash script that iterates over the configuration file names and invokes PHPUnit.

There are already some awesome sources how to get Hudson and PHP working. I'll list them here:

All those guides are already awesome and I would recommend choosing one of those to install Hudson, I think i can't add anything new to those. I have used Sebastians Howto, however i also like the third one. David Luhmans guide adds lots of details that are important to get the different parts of a build process to work.

Now what these tutorials all do is that they use a bash command to execute the build process or specifiy an Ant Build file. However there is also a Phing Build process plugin for Hudson that allows to specify the build.xml targets to execute in the process. From the "Available Plugins" list you can choose the "Phing plugin".

After installation you have to configure the Phing install. The Phing Plugin Wiki Page shows how to do this. You have to go to "Manage Hudson" => "Configure System" and look for Phing. There you find the dialog to configure your phing installations.

In the context of choosing a build script for your project you can now choose "Phing" instead of Ant:

You can enter the targets to build, for example on my local Hudson instance I only execute "test" for Doctrine 2, since I am not interested in the building and deployment onto the PEAR channel at this development stage.

From inside Netbeans you can then start builds by pointing to the Hudson instance. See this tutorial by one of the Hudson + Netbeans Developers. You can then start all the builds from inside Netbeans and be notified of the success or failure.

My RSS » Planet PHP » February 7, 2010

Feeds

Planet PHP

Troubleshoot – My PHP script is timing out

Posted: February 7th, 2010, 6:23pm MST by Venkat Raman Don

Resources for a PHP and Hudson CI Integration

Posted: February 7th, 2010, 4:25am MST by Benjamin Eberlei