I have two questions concerning the sleep() function in PHP:
Does the sleep time affect the maximum execution time limit of my PHP scripts? Sometimes, PHP shows the message "maximum execution time of 30 seconds exceeded". Will this message appear if I use sleep(31)?
Are there any risks when using the sleep()function? Does it cost a lot of CPU performance?
You should try it, just have a script that sleeps for more than your maximum execution time.
<?php
sleep(ini_get('max_execution_time') + 10);
?>
Spoiler: Under Linux, sleeping time is ignored, but under Windows, it counts as execution time.
It only affects script time not system calls like sleep(). There is apparently a bug where on Windows sleep() is included. Max execution time is about real-time, not CPU time or anything like that. You can change it however:
max_execution_time directive in your php.ini. This is a global setting;
Using ini_set() with the above directive. This will change it only for the currently executing script only for that execution;
set_time_limit(): also a local change.
As for the difference between the last two, I believe max_execution_time is a fixed quantity. Running:
ini_set('max_execution_time', 60);
will limit to the script to 60 seconds. If after 20 seconds you call:
set_time_limit(60);
the script will now be limited to 20 + 60 = 80 seconds.
From the PHP sleep() page, there's this user-contributed note:
Note: The set_time_limit() function
and the configuration directive
max_execution_time only affect the
execution time of the script itself.
Any time spent on activity that
happens outside the execution of the
script such as system calls using
system(), the sleep() function,
database queries, etc. is not included
when determining the maximum time that
the script has been running.
Others have already covered the basics of sleep() and PHP script execution time limit, but you should also be aware of another risk when using really long sleep periods.
Usually, when a browser sends a request to a server and does not receive any data from the server, the connection can time out. This time limit depends on the browser's configurations, but I've read that IE7 has a default value of just 30 seconds, while Firefox has a default value of 115 seconds--you can check your own configuration in Firefox by going to about:config and filtering for network.http.keep-alive.timeout (the time limit is specified in seconds).
Edit: I had the units for network.http.keep-alive.timeout and browser.urlbar.search.timeout mixed up. It is indeed in seconds, not tenths of a second.
a) Yes, it counts toward the time limit (so sleep(31) will trigger an error)
b) It does the opposite of costing CPU performance - it lets other applications use the CPU (when an application sleeps, the CPU usage of that application will be near 0%). Aside from taking time away from the user, I can't really think of any risks of using this.
Related
I have two questions concerning the sleep() function in PHP:
Does the sleep time affect the maximum execution time limit of my PHP scripts? Sometimes, PHP shows the message "maximum execution time of 30 seconds exceeded". Will this message appear if I use sleep(31)?
Are there any risks when using the sleep()function? Does it cost a lot of CPU performance?
You should try it, just have a script that sleeps for more than your maximum execution time.
<?php
sleep(ini_get('max_execution_time') + 10);
?>
Spoiler: Under Linux, sleeping time is ignored, but under Windows, it counts as execution time.
It only affects script time not system calls like sleep(). There is apparently a bug where on Windows sleep() is included. Max execution time is about real-time, not CPU time or anything like that. You can change it however:
max_execution_time directive in your php.ini. This is a global setting;
Using ini_set() with the above directive. This will change it only for the currently executing script only for that execution;
set_time_limit(): also a local change.
As for the difference between the last two, I believe max_execution_time is a fixed quantity. Running:
ini_set('max_execution_time', 60);
will limit to the script to 60 seconds. If after 20 seconds you call:
set_time_limit(60);
the script will now be limited to 20 + 60 = 80 seconds.
From the PHP sleep() page, there's this user-contributed note:
Note: The set_time_limit() function
and the configuration directive
max_execution_time only affect the
execution time of the script itself.
Any time spent on activity that
happens outside the execution of the
script such as system calls using
system(), the sleep() function,
database queries, etc. is not included
when determining the maximum time that
the script has been running.
Others have already covered the basics of sleep() and PHP script execution time limit, but you should also be aware of another risk when using really long sleep periods.
Usually, when a browser sends a request to a server and does not receive any data from the server, the connection can time out. This time limit depends on the browser's configurations, but I've read that IE7 has a default value of just 30 seconds, while Firefox has a default value of 115 seconds--you can check your own configuration in Firefox by going to about:config and filtering for network.http.keep-alive.timeout (the time limit is specified in seconds).
Edit: I had the units for network.http.keep-alive.timeout and browser.urlbar.search.timeout mixed up. It is indeed in seconds, not tenths of a second.
a) Yes, it counts toward the time limit (so sleep(31) will trigger an error)
b) It does the opposite of costing CPU performance - it lets other applications use the CPU (when an application sleeps, the CPU usage of that application will be near 0%). Aside from taking time away from the user, I can't really think of any risks of using this.
I would like to set a wall clock time limit on execution of PHP scripts on my Apache server.
Unfortunately, set_time_limit() and the max_execution_time directive set limits on execution time, not wall clock time, as described in the former's documentation:
Note:
The set_time_limit() function and the configuration directive max_execution_time only affect the execution time of the script itself. Any time spent on activity that happens outside the execution of the script such as system calls using system(), stream operations, database queries, etc. is not included when determining the maximum time that the script has been running. This is not true on Windows where the measured time is real.
However, in general I care about wall clock time, not execution time. Of course, ideally neither limit would ever come into play - but if a script, say, stalls on a deadlocked database query, web request, or file system write for 30 seconds, I want it to die. The fact that the time isn't being spent on actual computation by PHP is irrelevant to me. In fact, I struggle to imagine any situation at all in which an execution time limit would be preferable to a wall-clock time limit (but perhaps I just lack imagination!)
How can I set a real (wall clock) time limit on script execution instead, which would in general be more useful?
I have a PHP script running a loop which could go on for hours on end. However after about 50 minutes I get the following error although the script is far beyond 60 seconds:
Fatal error: Maximum execution time of 60 seconds exceeded in
/path/script.php on line 275
The memory usage by the time the script fails is 11359848 Bytes - 10.8336 MB.
Any ideas what sort of thing could actually be causing the script to trip out like this?
The maximum execution time is not real time but CPU time.
So if send e.g. a HTTP request that takes 10 hours to finish (i.e. you wait for I/O) you can easily stay within the 60-second limit. But if try breaking a hash using brute force (i.e. something where the script is actually doing something) you'll hit the time limit after pretty much 60s of real time.
The solution for your problem is pretty simple: set_time_limit(0); disables the time limit unless PHP is running in safe_mode, but if that's the case it's time to chance the hosting company.
I have a PHP class, once called, sets the time limit to 60 seconds. The only special thing about this class is that it uses curl_multi_exec().
set_time_limit(60);
ini_set('max_execution_time', 60);
The problem is that under Apache's /server-status page, this page and another one that uses single threaded curl run past their max_execution_time and reach up to 200 seconds, sometimes!
What am I missing? Is there a way to setup Apache to terminate scripts (or even connections) running for longer than say 90 seconds?
From the manual:
The set_time_limit() function and the configuration directive max_execution_time only affect the execution time of the script itself. Any time spent on activity that happens outside the execution of the script such as system calls using system(), stream operations, database queries, etc. is not included when determining the maximum time that the script has been running.
Because curl requests fall under this category, time spent waiting for a request to complete will not be counted. You should set the curl setting CURLOPT_TIMEOUT to a lower value, or monitor the time spent in executing your script yourself.
Aha! When you set that configuration, the ticker resets itself, example:
sleep(10);
set_time_limit(20);
sleep(10);
set_time_limit(5);
sleep(10); // dies after 5 seconds
Total running time is ~30s.
With regards to curl_exec_multi, you can set the CURL timeout option instead of the PHP one. This depends on who would rather die in your opinion - the curl connection, or the full request.
I have few doubts about maximum execution time set in php.ini.
Assuming max_execution_time is 3 minutes, consider the following cases:
I have a process which will end in 2 minutes.
But it's in a loop and it should work 5 times. So it become 10 minutes.
Will the script run properly without showing error for timeout? Why?
PHP function just prints the data and it will take only 2 minutes.
But the query execution is taking 5 minutes.
Will the script run without error? Why?
My single php process itself take 5 minutes.
But am calling the script from command line.
Will it work properly? Why?
How are memory allowed and execution time related?
If execution time for a script is very high
But it returns small amount of data
Will it affect memory or not? Why?
I want to learn what is happening internally, that is why am asking these.
I don't want to just increase time limit and memory limit.
The rules on max_execution_time are relatively simple.
Execution time starts to count when the file is interpreted. Time needed before to prepare the request, prepare uploaded files, the web server doing its thing etc. does not count towards the execution time.
The execution time is the total time the script runs, including database queries, regardless whether it's running in loops or not. So in the first and second case, the script will terminate with a timeout error because that's the defined behaviour of max_execution_time.
External system calls using exec() and such do not count towards the execution time except on Windows. (Source) That means that you could run a external program that takes longer than max_execution_time.
When called from the command line, max_execution_time defaults to 0. (Source) So in the third case, your script should run without errors.
Execution time and memory usage have nothing to do with each other. A script can run for hours without reaching the memory limit. If it does, then often due to a loop where variables are not unset, and previously reserved memory not freed properly.