Does Sleep Time Count For Execution Time Limit

Does sleep time count for execution time limit?

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.

PHP does not respect the maximum execution time set

"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."

Copied from: sleep().

In other words: Sleep() was a bad choice for testing maximum execution time.

max_execution_time and sleep()

while setting the set_time_limit or max_execution_time the duration of sleep() will be ignored in the execution time. The following illustrates:

<?php

  set_time_limit(20);

  while ($i<=10)
{
    echo "i=$i ";
    sleep(100);
    $i++;
}

?>

Output:

i=0 i=1 i=2 i=3 i=4 i=5 i=6 i=7 i=8 i=9 i=10.

Taken from http://www.drupaluser.org/php_manual/function.set-time-limit.html

i think this may help.

Why does sleeping increase the execution time of an independent piece of code that is executed before/afterwards?

I am quite sure that this is caused by the CPU throttling. When the OS scheduler detects there is little work to do, the CPU frequency lowers to save power.

When you do a lot of sleeps, you are telling the scheduler that you are not in such a hurry, and the CPU can take it easy.

You can see that this is the case by running a CPU intensive task in another window, with low priority. For example, in Linux you can run:

$ nice bash -c 'while true ; do : ; done'

And at the same time, in another window run your program:

$ cargo run --release
loop_time 1.00ms    => 3.13ms
loop_time 2.00ms    => 3.17ms
loop_time 3.00ms    => 3.19ms
loop_time 4.00ms    => 3.13ms
loop_time 5.00ms    => 3.16ms
loop_time 6.00ms    => 3.22ms
loop_time 7.00ms    => 3.14ms
loop_time 8.00ms    => 3.15ms
loop_time 9.00ms    => 3.13ms
loop_time 10.00ms   => 3.18ms
loop_time 11.00ms   => 3.14ms
loop_time 12.00ms   => 3.17ms
loop_time 13.00ms   => 3.15ms
...

Avoiding this depends on your OS. For example, in Linux, you can fiddle with sys/devices/system/cpu/* options. I think that UPower provides some functions to manage it from a non-root application. It would be nice if there were a crate that managed this cross-system, but I don't know of any.

An easy but hacky way to fix this, if you don't mind the wasted power, is just to run an idle thread with a busy loop.

std::thread::spawn(|| {
    use thread_priority::*; //external crate thread-priority
    let thread_id = thread_native_id();
    set_thread_priority(
        thread_id,
        ThreadPriority::Min,
        ThreadSchedulePolicy::Normal(NormalThreadSchedulePolicy::Idle),
    )
    .unwrap();
    loop {}
});

Naturally, if you just want to avoid throttling in this piece of code, you can do a busy wait:

    //if loop_time > elapsed {
    //    std::thread::sleep(loop_time - elapsed);
    //}
    // Busy-wait the remaining time, to avoid CPU throttling
    while loop_time > before.elapsed() {
        //you may want to try both with and without yield
        std::thread::yield_now();
    }

What happens when I sleep in GAS ? (execution time limit workaround)

The statement that the server handler function calls aren't independent processes because they "are created from inside the function itself" isn't quite true.

You've set up a checkBox element chk1 with a server handler doSomething. Whenever the
checkBox is checked, then, an event is dispatched to the server. (...and your script is causing those events with every chk1.setValue() call) The checkBox and surrounding UI code is running in your browser - click "show source" or use an explorer to see what's been served to your browser by the google servers. (Warning - it's obfuscated. But you might recognize some of your strings, and from that your client-side code.)

Here's what we're told in the documentation for Class ServerHandler:

When a ServerHandler is invoked, the function it refers to is called on the Apps Script server in a "fresh" script.

That's the key to extending your operating time: each dispatched event results in invocation of doSomething() in a completely new operating context - it's like you've opened the script editor in a different browser, and clicked "run" on your script. The "fresh" script has no access to var values of previous run... but it is also given it's own set of operating restrictions, including timers.

PS: You should make sure that server-side handler is "thread safe" by using Lock, since you're accessing shared resources that may be accessed by multiple instances of the doSomething() callback. Related to that, it's possible to hit another limit with this script:

Just for fun, I commented out .setVisible(false) on chk1, so the checkBox would be visible. I then rapidly clicked it several dozen times. The time display ran out-of-order, and eventually the above error popped up. (minutes later) It's an artificial situation, of course, but still an error state that's easily avoided.

PPS: I wonder if one could use the same technique to dispatch multiple parallel server-side handlers, and thus reduce the elapsed time to complete the whole job?

Is CPU execution time different in Loop with Sleep() and Long Loops without sleep(), with both having the same total running time?

They will be concerned with the CPU Execution Time, not the total running time unless connections are an issue and you're using a lot of them (which it doesn't sound like you are).

Running time, as in a stopwatch, doesn't matter much to a shared host, if your loop runs for 3 years but only uses 0.01% CPU doing it, it doesn't impact their ability to host. However if you ran for 3 years at 100% CPU, that directly impacts how many other applications/VMs/whatever can be run on that same hardware. This would mean more servers to host the same number of people which means money...that they care about.

For the question in the title: they are very different. With sleep() and the same amount of total time, that means the actual work the CPU is doing is much less because it can do the work, sleep/idle, and still finish in the same amount of time. When you're calling sleep() you're not taxing the CPU, it's a very low-power operation for it to keep the timer going until calling your code again.

Should i use Sleep() or just deny them

The sleep does not use any CPU or Memory which is not already used by the process accepting the call.

The problem you will face with implementing sleep() is that you will eventually run out of file descriptors while the attacker site around waiting for your sleep to time out, and then your site will appear to be down to any other people who tries to connect.

This is a classical DDoS scenario -- the attacker do not actually try to break into your machine (they may also try to do that, but that is a different storry) instead they are trying to harm your site by using up every resource you have, being either bandwidth, file descriptors, thread for processing etc. -- and when one of your resources are used up, then you site appears to be down although your server is not actually down.

The only real defense here is to either not accept the calls, or to have a dynamic firewall configuration which filters out calls -- or a router/firewall box which does the same but off your server.

Setting a 1 second time limit does not stop the script after 1 second

The PHP time limit is only enforced when the program is actually executing. sleep delays do not necessarily count as such, as per the manual:

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.

Php max_execution_time ignored

Sleep Time doesn't count towards max_execution_time or in other words:
Sleep Time doesn't count as execution time.

See: Does sleep time count for execution time limit?

---

Related Topics