[upupandup]

up to 10ms CPU time per request

Not much of a room here it seems. AWS still offers more generous CPU time.

In fact any price move by new entrants can be countered by AWS going forward.

So AWS users benefit from not moving. Simply wait for others to reduce their prices and expect AWS to do the same.

[vamega]

The key difference is that unlike lambda where you are charged for network waiting time, Cloudflare from what I can tell, doesn't count time the CPU is suspended for networking operations.

I use a cloudflare worker for DDNS updates, and it runs on the free tier. If the 10ms included network time, my worker would consistently timeout, but it hasn't timed out yet so I must conclude that it doesn't count network time.

[kkielhofner]

This is absolutely correct. I have a worker function that takes ~200ms clock time to execute but most of that is waiting on I/O and doesn’t count against CPU.

Last I checked I think our median is 6ms (against a limit of 50 IIRC) on Workers Bundled.

[Zababa]

There's some clarification on the "limits" page [1]:

> Most Workers 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 10 ms on the Free plan and up to 50 ms for Bundled Workers on the Paid Plan. The Paid Plan also offers up to a 30 second duration for increased compute time. The 10 ms 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.

My understanding is that you could consume 1/10 ms of CPU time every hour, and your worker would hit the limit only after 100 hours for the free tier. This would also work with the paid plan - bundled, with up to 500 hours. However, this wouldn't work with the paid plan - unbound, as you pay GB-s, which are counted even if the CPU is not used. From the "Duration" part of "Limits":

> Duration is the measurement of wall-clock time. This is measured in Gigabyte-seconds (GB-s). When a Worker is executed, it is allocated 128 MB of memory . As the Worker continues to execute that memory remains allocated, even during network IO requests.

> For example, when a Worker executes via a scheduled event , it executes for four seconds, including network-bound IO time: 4s x 0.125GB (or 128Mb) = .5 GB-s.

There is also a pricing page that's more detailed [2].

[1]: https://developers.cloudflare.com/workers/platform/limits/

[2]: https://developers.cloudflare.com/workers/platform/pricing/