Wait, huh? I assumed the CPU time for the unbound model was the same measure as the one it shows you for workers on the standard plan, usually measured in single digit milliseconds as idle time while waiting for responses doesn't count. Guess it's not?
For better or worse, Unbound's billing is designed to be apples-to-apples comparable to Lambda. Lambda bills for real time (or, technically, memory-time), not for CPU usage. Although, for 128MB instances, Lambda throttles the CPU to something like 1/8 speed. Since Workers doesn't throttle, Workers Unbound billing is actually based on either real time or 8x CPU time, whichever is larger, in order to maintain direct comparability.
On the other hand, CPU limits are based on CPU time. In the original "Bundled" pricing model, we didn't charge for time, but we did limit CPU time to 50ms. Unfortunately, we discovered that very few people actually understand what this means, and most users assumed we were limiting real time to 50ms, leading to a lot of confusion. So that was another motivation for basing billing on real time instead.
Billing based on real time makes sense to me, because the resources for that worker, particularly memory, are allocated for all of that time, regardless of how much CPU time is used.
3 comments
[ 0.20 ms ] story [ 17.7 ms ] threadOn the other hand, CPU limits are based on CPU time. In the original "Bundled" pricing model, we didn't charge for time, but we did limit CPU time to 50ms. Unfortunately, we discovered that very few people actually understand what this means, and most users assumed we were limiting real time to 50ms, leading to a lot of confusion. So that was another motivation for basing billing on real time instead.