Cloudflare Worker 请求上下文中的 CPU 时间和 Wall time 是多少？

Question

如果您在免费计划中看到 Cloudflare Workers 的定价部分，他们有以下内容

每个请求最多 10ms CPU 时间

并在以下付费计划中

每个请求最多 30 秒的挂机时间

通常，执行一个执行有用操作的脚本需要超过 10 毫秒的时间。根据任务的不同，甚至 30 秒的墙上时间也可能很短。

如果您查看 Worker 的文档限制：CPU 运行时部分，它有

大多数 Worker 请求消耗的时间不到一毫秒。很少能找到正常运行的 Workers 脚本超出 CPU 时间限制的情况。免费计划中的工作人员最多可消耗 10 毫秒，付费计划中的捆绑工作人员最多可消耗 50 毫秒。付费计划还提供长达 30 秒的持续时间，以增加计算时间。免费计划的 10 毫秒津贴足以满足大多数用例（包括应用程序托管）的执行时间。

Workers 脚本的实际运行时间没有限制。只要发送请求的客户端保持连接，Workers 脚本就可以继续处理、发出子请求并代表该请求设置超时。当客户端断开连接时，与该客户端请求关联的所有任务都将被取消。您可以使用 event.waitUntil() 将取消再延迟 30 秒，或者直到传递给 waitUntil() 的 Promise 完成。

虽然就 CPU 时间的一般意义而言，本文中提到的 Wall time是正确的。我不认为这在这种情况下是准确的含义，因为在链接的帖子中，CPU 时间是内核或用户空间中的代码执行时间。

CPU time per request与 AWS Lambda 中的代码执行 CPU 时间也不相似，因为它提到了以下内容

Workers 脚本的实际运行时间没有限制。

因此脚本的实际运行时间（即：CPU 执行时间）并不像 AWS Lambda 中那样限制为 15 分钟。

然后

• Cloudflare 工作线程中每个请求 10 毫秒的 CPU 时间是多少？
• 付费计划中提到的每个请求30 秒的墙时间是多少？

Answer 1

“CPU 时间”是指 CPU 主动执行 JavaScript 代码的时间量。具体来说，这不包括 CPU 等待某些事情发生的时间，例如等待 afetch()完成或 asetTimeout()触发。

许多 Worker 的执行时间不到一毫秒。例如，如果您只是更改每个请求的标头，然后将其发送到另一台服务器，则您的 Worker 每个请求可能只需要几百微秒的 CPU 时间（因此，十分之几毫秒）。在免费计划下，worker 每个请求的 CPU 时间被限制为 10 毫秒，这实际上足够做很多事情了。

“墙上时间”是指通过墙上的时钟测量的时间，即现实世界时间。与 CPU 时间不同，wall time 包括等待时间。因此，如果您fetch()向其他服务器执行（HTTP 请求），并且需要 3 秒才能响应，则整个过程可能需要不到 1 毫秒的 CPU 时间，但需要 3 秒的实际时间。

付费计划指定请求处理的时间限制为 30 秒。事实上，这里强制的限制还是 CPU 时间，而不是实际运行时间。因此，只要请求不是一直在执行代码，请求所花费的时间可能会超过 30 秒。但请注意，当请求时间超过 30 秒时，请求被随机中断的变化就会上升。例如，运行时间非常长的请求可能会遇到 TCP 超时或随机网络断开连接。此外，当 Workers Runtime 收到代码更新时，它会为所有正在进行的请求提供 30 秒（实际时间）来完成，然后再取消它们。因此，请求运行时间超过 30 秒的应用程序需要实现重试逻辑，以防随机断开连接。（即使对于较短的请求，重试逻辑也是一个好主意，因为任何长度的请求都可能发生随机中断，但运行时间超过 30 秒的请求会承担更高的风险。）