cloudflare dashboard reporting wrong GB-sec execution duration for workers
Original message was deleted
CA few things which may be worth mentioning:
- That Execution Duration is a sum across all requests in that timespan, not per request
- Execution Duration is calculated per Worker at a flat rate, as if it was constantly consuming the full 128 MB, ex: a worker being active for 4s = 4s x 0.125GB (or 128Mb) = .5 GB-s . Execution Duration is also wall time, including time the worker is just waiting on the fetch request/i/o to return
- You're not billed on Execution Duration unless for Durable Objects or if you're an old Enterprise customer, paygo is all Standard which is entirely off the CPU Time now
CWhat you are billed on depends on your usage model
CIf you're not Enterprise, then
All Workers are Standard/cpu time & requests
Durable Objects are billed on duration & requests
Enterprise still may have the old Unbound billing for duration afaik
All Workers are Standard/cpu time & requests
Durable Objects are billed on duration & requests
Enterprise still may have the old Unbound billing for duration afaik
Cyou'd have to be more specific on what exactly you mean ont he pricing page as well, that page is like 20 pages long. There is a section talking about the old billing models
Cthen yea, you should be billed on just CPU Time. I don't think anything you posted conflicts with that, You can still see Execution Duration in your Workers Metrics without being billed on it. In the Workers & Pages overview in the top right you should be able to see your current usage, ex:
Cimo the far bigger issue with Unbound that I saw repeatedly was that duration was too hard to calculate and confusing
CFor Duration billing:
2 Cloudflare will bill for duration charges based on the higher of your wall time or CPU time, with a multiple of 8 applied to the CPU time to account for the processing power allotted to your Worker. Cloudflare will not bill for wall time duration charges beyond the execution limit given.
3 Duration billing will charge for the 128 MB of memory allocated to your Worker, regardless of actual usage. If your account has significant traffic to a single Worker, multiple instances of that Worker may run in the same isolate on the same physical machine and share the 128 MB of memory. These Workers are still billed as if they were separate instances, with each being charged as if it had its own 128 MB of memory.
Cso it wasn't always just wall time, and it was confusing with each worker always getting 128 mb of memory
Cthere's limits on subrequests though and still some cpu time cost for processing them
CThe runtime isn't Rust, it's just V8
CSome JS logic and the rest is V8, Chromium's JS Engine
CCbut yea it's not too costly per subrequest
Cps. How is this any different then now? That is what CF is doing, billing for the total amount of cpu time
CI don't know of anything wrong with it and math seems to check out
CIf you're concerned about your bill, check past invoices
CCpu time is never in GB-sec so confused about what you mean by that
CIt's whatever one is greater
Cloudflare will bill for duration charges based on the higher of your wall time or CPU time, with a multiple of 8 applied to the CPU time to account for the processing power allotted to your Worker. Cloudflare will not bill for wall time duration charges beyond the execution limit given.
Cexcept they're doing cpu time * 8
Cand that's the new billing model, not the old one
CI think you're confusing things
Calthough the pricing is a bit confusing on its own
CThere's various Workers billing Models:
Standard - Billed on Requests and CPU Time, everyone on Pay as you go should be on this now
Old:
Bundled - Billed on Requests, static cpu time of 50ms
Unbound - Billed on Requests & Duration (duration calculation above, taking in account cpu time * 8 or wall clock)
Durable Object Pricing for Everyone:
Billed as Unbound - on Requests and Duration, although unlike Unbound Duration is shared among all executing requests for that specific DO
You can still see all metrics though, regardless of plan
Standard - Billed on Requests and CPU Time, everyone on Pay as you go should be on this now
Old:
Bundled - Billed on Requests, static cpu time of 50ms
Unbound - Billed on Requests & Duration (duration calculation above, taking in account cpu time * 8 or wall clock)
Durable Object Pricing for Everyone:
Billed as Unbound - on Requests and Duration, although unlike Unbound Duration is shared among all executing requests for that specific DO
You can still see all metrics though, regardless of plan
CDuration billing is still something worth talking about/good to know as it's what Durable Objects still use, but doesn't apply for normal workers unless you are on an old workers plan, that only Enterprises have afaik
CIf you go to the Workers & Pages overview and only see Requests & CPU Time and not Duration Metrics, should be on latest
Cit's just for Unbound/Durable Object billing, for Duration based billing, not Standard, which is just straight cpu time
C(and requests)
CCan you explain why exactly you don't think you being charged correctly?
CBecause the Duration metric exists and you're using that?
CYou're always going to see all the metrics despite usage model, it's only going to be using CPU Time if you're on standard though
CIn your first message you said you saw Duration somewhere for your entire account, where did you see that metric exactly?
CWhy are you trying to conflate Execution Duration with CPU time?
CThey're completely different
CYour account total cpu time should match up with the total amount of cpu time across all your workers
Cex, if we take 110k requests from that worker times the median cpu time (110k * 3.5), we get 385,000 cpu ms, which is half your account's usage on that single worker
C(of course that's not how the billing works, its by the exact amount of cpu ms, not median, but just showing as an example)
CCpu Time = Cpu Time
Execution Duration = math on cpu time or walltime times memory
Execution Duration = math on cpu time or walltime times memory
Cyea that's one good reason why unbound/duration based billing is gone, it is confusing
CStandard doesn't
CStandard Billing, the new default, which you are on
COn Standard, all you need to worry about is requests and cpu time
Cwhen you look at your metrics page, block execution time from your sight if it's confusing you lol
Cit's just metrics, meant to help you understand your usage (and Unbound billing used to be around, making that very necessary to understand your billing
Cehh that's the confusing thing about execution duration, it's not exactly
CExecution Duration = (greater or wall time, or cpu time * 8) times memory usage (Static 128 mb)
Cno, that is just the normal calculation for Execution Duration
C(which again, you are not billed on for Standard Billing, Standard is just Cpu time and requests, nothing else)
Cto confuse you
CI mean it used to be important with the old billing models around, and like I said I think there is still some enterprises on the old models
Cand it could still be useful if you intend on converting logic in a Worker to a Durable Object, because the math is pretty hard to do yourself ahead of time
