It seems like a win for most use cases, however it's a major setback for cpu-heavy use cases too:
- the 5$/month subscription only includes 30 million milliseconds when it was previously including 500 million (10 million invocations of up to 50ms cpu time each)
- for longer-running workers, the cost goes up 13x (!!!) to $0.072/hour for CPU time compared to $0.0056/hour in previous Unbound plan (advertised as GB-sec but each worker had 128MB so 1/8th)
(Quick background for others reading this: Previously, Workers had two pricing plans. The "bundled" plan was priced purely on number of requests but had an enforced 50ms CPU time limit. The "unbound" plan was priced on requests and "duration" with much larger limits.)
> - the 5$/month subscription only includes 30 million milliseconds when it was previously including 500 million (10 million invocations of up to 50ms cpu time each)
I don't think it's quite realistic to multiply the 50ms per-request CPU time limit under the old "bundled" plan by number of requests in order to get total CPU time available. Realistically apps had to stay way below that limit otherwise random variability could cause them to go over and serve errors frequently. The vast majority of apps on the old "bundled" plan only used 1-2ms per request; anything CPU-heavy had to use the "unbound" plan.
> - for longer-running workers, the cost goes up 13x (!!!) to $0.072/hour for CPU time compared to $0.0056/hour in previous Unbound plan (advertised as GB-sec but each worker had 128MB so 1/8th)
"Duration" under the previous "unbound" plan was actually based on the maximum of the wall time duration or 8x the CPU time. This 8x multiplier exists because Workers' pricing was trying to be directly comparable to Lambda pricing, but at the 128MB RAM level, Lambda throttles CPU to 1/8. Workers does not throttle CPU at all, but wanted the same workload to come out to the same work units, so multiplied CPU time by 8 instead. So the difference with the new pricing is not that large for heavy CPU users.
(I'm the tech lead for Workers, though I'm not closely involved with pricing decisions.)
2 comments
[ 3.5 ms ] story [ 24.2 ms ] thread- the 5$/month subscription only includes 30 million milliseconds when it was previously including 500 million (10 million invocations of up to 50ms cpu time each)
- for longer-running workers, the cost goes up 13x (!!!) to $0.072/hour for CPU time compared to $0.0056/hour in previous Unbound plan (advertised as GB-sec but each worker had 128MB so 1/8th)
> - the 5$/month subscription only includes 30 million milliseconds when it was previously including 500 million (10 million invocations of up to 50ms cpu time each)
I don't think it's quite realistic to multiply the 50ms per-request CPU time limit under the old "bundled" plan by number of requests in order to get total CPU time available. Realistically apps had to stay way below that limit otherwise random variability could cause them to go over and serve errors frequently. The vast majority of apps on the old "bundled" plan only used 1-2ms per request; anything CPU-heavy had to use the "unbound" plan.
> - for longer-running workers, the cost goes up 13x (!!!) to $0.072/hour for CPU time compared to $0.0056/hour in previous Unbound plan (advertised as GB-sec but each worker had 128MB so 1/8th)
"Duration" under the previous "unbound" plan was actually based on the maximum of the wall time duration or 8x the CPU time. This 8x multiplier exists because Workers' pricing was trying to be directly comparable to Lambda pricing, but at the 128MB RAM level, Lambda throttles CPU to 1/8. Workers does not throttle CPU at all, but wanted the same workload to come out to the same work units, so multiplied CPU time by 8 instead. So the difference with the new pricing is not that large for heavy CPU users.
(I'm the tech lead for Workers, though I'm not closely involved with pricing decisions.)