十毫秒算的是处理器时间

提问给出两个限制，对象是 Workers 和 Pages Functions。每个请求最多占用十毫秒处理器时间。每天最多十万次，按世界协调时的零点换日。

等待不算进这十毫秒

这十毫秒量的是处理器真正在跑的时间，不是请求从进到出的墙钟。发给别的服务、干等响应的那段，不进这个预算。把同一段计算改成异步，不会让计算变少。异步只改变等待的写法。

对话建议避免复杂计算和循环，把耗时操作挪到客户端或其他后端，并缓存经常读的数据。挪走和缓存，才会少用这十毫秒。并行等待不会。

十万次是提问里的每日上限。对话说小型到中型往往够用，流量会超过时再考虑客户端缓存、用分发减少打到函数的次数，或换更高配额的计划。这些是当时的建议，不是给你的账号测出来的剩余次数。

去仪表板看你自己的数字

查看步骤按对话所写。打开 dash.cloudflare.com 并登录。左侧进入 Workers 与 Pages。Workers 看概览里的用量。Pages 先选项目，再打开 Functions。更细的图在 Analytics，包括每日请求和处理器时间。账户一级从 Overview 进 Workers 的 Manage。实时日志在项目的 Logs。对话还说可以用接口取用量，但没有给出路径。有些分析只在付费计划里出现。免费计划里看不到某张图，先按这个说明理解，不要当成统计坏了。

达到上限时，对话要求返回明确错误或走备用，而不是让请求挂住。它没有给出具体状态码。备用是你自己的降级，不是平台附送的第二配额。

计划上的数字会改。提问里的十毫秒和十万次，用来对照你打开页面时看到的两项。页面上的数和提问不一致时，以页面为准。不要把这篇里的两个数写成永久条款。

函数并不适合每一种工作。对话问的是是不是所有功能都要放在这里。重计算放在函数里，会先撞上十毫秒。能在构建时算完的，不要留到每次请求。

缓存命中不再进函数，才少算每日次数。缓存没配上、请求仍打到函数，次数照算。客户端缓存和边缘缓存是两条，对话把它们都算进减少直接请求的办法。

日志用来看单次请求为什么慢。用量图用来看一天有没有接近十万。两处都看，才知道是单次计算超了，还是次数超了。

处理器时间在概览和 Analytics 里都可能出现。名称以页面上的英文为准。对话用了 CPU 时间这个说法。找的时候认这项，不要去找墙钟耗时。

换计划之前先看 Manage 里当前计划的限额。对话把升级写成流量会超过时的选择。没超过就不必为这两个数升级。

错误处理要在达到限制时仍能返回。对话没有写重试可以把十万次变成更多。重试会计入新的请求。次数紧的时候，重试会更快用完当天的配额。

世界协调时零点换日。按本地时区的午夜去估剩余，会差几个小时。看图时认的是那个零点，不是本地午夜。