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

Question

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

每个请求最多 10 毫秒的 CPU 时间

在付费计划中

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

执行一个有用的脚本通常需要超过 10 毫秒的时间。根据任务的不同，即使是 30 秒的挂壁时间也可能很短。

如果您查看 Worker 的文档 limits: CPU runtime 部分，它有

大多数 Worker 请求消耗的时间不到一毫秒。这是罕见的 找到一个正常运行的超过 CPU 时间的 Workers 脚本 限制。一个 Worker 在免费计划上最多可以消耗 10 毫秒，最多可以消耗 50 毫秒 对于付费计划的捆绑工人。付费计划还提供高达 30 秒的持续时间以增加计算时间。上的 10ms 津贴 免费计划对于大多数用例来说是足够的执行时间，包括 应用程序托管。

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

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

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

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

所以脚本实际运行时间（即：CPU 执行时间）并不像 AWS Lambda 那样限制在 15 分钟。

然后

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

Answer 1

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

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

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

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