What is CPU time and Wall time in the context of Cloudflare Worker request?
Asked Answered
S

1

9

If you see the pricing section of Cloudflare Workers here in the free plan they have the following

Up to 10ms CPU time per request

and in paid plan following

Up to 30s wall time per request

Typically it takes more time than 10ms to execute a script that does something useful. Even 30s wall time can be short depending on the task.

If you look at Worker's documentation limits: CPU runtime section it has

Most Worker requests consume less than a millisecond. It is rare to find a normally operating Workers script that exceeds the CPU time limit. A Worker may consume up to 10ms on the free plan and up to 50ms for Bundled Workers on the Paid Plan. The Paid Plan also offers up to a 30 second duration for increased compute time. The 10ms allowance on the free plan is enough execution time for most use cases including application hosting.

There is no limit on the real runtime for a Workers script. As long as the client that sent the request remains connected, the Workers script can continue processing, making subrequests, and setting timeouts on behalf of that request. When the client disconnects, all tasks associated with that client request are canceled. You can use event.waitUntil() to delay cancellation for another 30 seconds or until the promise passed to waitUntil() completes.

While in generic sense meaning of CPU time, Wall time mentioned in this post are correct. I do not think it is the accurate meaning in this context, since in the post linked, CPU time is the code execution time either in kernel or user space.

CPU time per request is not similar to the code execution CPU time in AWS Lambda either, since it mentions following

There is no limit on the real runtime for a Workers script.

So script real runtime (ie: CPU execution time) is not limited to 15 minutes like in AWS Lambda.

Then

  • What is 10ms CPU time per request in Cloudflare workers?
  • And what is the 30s wall time per request mentioned in the paid plan?
Shastashastra answered 10/8, 2021 at 2:31 Comment(1)
Does this answer your question? What specifically are wall-clock-time, user-cpu-time, and system-cpu-time in UNIX?Albur
S
19

"CPU time" means the amount of time that the CPU is actively executing your JavaScript code. This specifically does not include time when the CPU is waiting for something to happen, such as waiting for a fetch() to complete or a setTimeout() to fire.

Many Workers take less than a millisecond of CPU time to execute. For example, if you are simply changing a header on each request and then sending it on to another server, your Worker will probably take only a couple hundred microseconds of CPU time per request (so, a couple tenths of a millisecond). Under the free plan, workers are limited to 10ms of CPU time per request, which is actually enough time to do a lot of stuff.

"Wall time" refers to the time as measured by a clock on the wall, i.e. real-world time. Unlike CPU time, wall time includes time spent waiting. So, if you perform a fetch() (HTTP request) to some other server, and it takes 3 seconds to respond, the whole thing may take less than a millisecond of CPU time, but 3 seconds of wall time.

The paid plan specifies a 30-second limit on request processing. In fact, the enforced limit here is again on CPU time, not wall time. So, a request can take much longer than 30s, as long as it isn't executing code the whole time. However, note that when requests take longer than 30 seconds, the change that a request is randomly disrupted go up. For example, a very long-running request may suffer TCP timeouts or random network disconnects. Additionally, when the Workers Runtime receives a code update, it gives all in-flight requests 30 seconds (of wall time) to finish up before it cancels them. Applications whose requests run longer than 30 seconds therefore need to implement retry logic in case of a random disconnect. (Retry logic is a good idea even for shorter requests, since random disruptions are possible for requests of any length, but requests running longer than 30 seconds bear higher risks.)

Swanger answered 10/8, 2021 at 13:46 Comment(5)
Thanks for the explanation! Is not it confusing paid plan have 30s wall time mentioned, but what is actually enforced is CPU time? What is the enforced limit of CPU time on paid plan? 30 * 1000 ?Shastashastra
The hard limit is 30s of CPU time. However, as I described above, if a request has run for more than 30s wall time, then it might be canceled at the Workers Runtime's discretion. That's why we document it as a 30s wall time limit -- because after that point, there's no guarantees.Swanger
So it is possible to treat this "wall time" as "response time"? i.e. how much time worker needs to response to request.Uhhuh
@Uhhuh that's correct. In 30s your function should finish, that includes returning response.Abernethy
Thanks a ton for the great explainer. <3Wast

© 2022 - 2024 — McMap. All rights reserved.