Which job schedulers fire on time? We tested ten. 的封面图片

Mike Gorman

我们为 smplkit 打造的应用基础设施产品之一是一款名为 Smpl Jobs 的 HTTP 任务调度器。当然，我们希望它能与竞品相比更具优势，但我们想知道它在真正重要的方面——准时发出 HTTP 请求——的表现到底如何。于是我们决定一探究竟。

参赛选手

测试设置

思路很简单：让调度器在整点向某个公开端点发送请求，并记录请求到达的日期/时间。整点后经过的毫秒数即为偏差（skew）：偏差越小，说明调度器越“准时”。

虽然思路简单，但要找到一个既能让调度器访问，又能捕获并存储接收时间的公开端点却并不容易。最终，我们需要的是一个通用的基准测试托管网站，能通过 POST JSON 消息来标识基准、测试对象，并记录请求到达的日期/时间。我们找不到符合需求的现成方案，于是自己搭建了一个。三周后，smplmark.org 正式上线，随时准备接受调度器测试。

我们创建了基准测试，定义了测试对象，并配置每个调度器向 smplmark 的 测量 API 发送请求，附带包含基准、运行和被测调度器 ID 的 JSON 负载。smplmark 会记录每次测量创建的日期/时间；通过 created_at mod 3600000 推导出单独的 skew 指标，即整点后经过的毫秒数。

每位参赛者均运行在免费阶层——或接近免费：其中几款每月仅收取约 1 美元费用。部分原因是为了公平，主要是为了让账单接近零。

为什么我创建 smplmark.org

一些缺陷

我们已知的测试方法存在四个缺陷：

  1. 偏差按小时取模，因此如果调度器恰好晚 60.1 分钟触发，实际看起来只晚 6 秒。这是边缘情况：唯一可能因回绕而受影响的是 GitHub Actions，而它的偏差是以分钟计的巨大误差，而非秒级。回绕也可能反向影响：提前到达的请求会被记录为接近一小时晚。但接近回绕值的到达记录仅属于 GitHub Actions，其不可靠性显而易见（且有 充分文档记录）。
  2. 端点位于美国东部，运行在美国西部或欧洲的调度器会承担网络延迟，而美国东部的调度器则无此负担。但这仅为几毫秒，调度器引擎本身才是决定因素。
  3. smplmark.org 本身运行在 Cloudflare 上，因此 Cloudflare Workers 可能具有主场优势，其请求可能从未离开 Cloudflare 网络。
  4. 偏差依赖 smplmark 的时钟。smplmark 运行在 Cloudflare 上，其时钟通过 NTP 同步；我们并未独立验证。如果该时钟发生漂移，所有对象的偏差都会同等偏移——排序会保持不变，但绝对数值会改变。调度器自身的时钟不会被校正：当其时钟显示到达时间时触发，正是本次测试的一部分。

排行榜

以下是当前结果。下方图片为固定快照，因此我们引用的数值会与图表保持一致；实时看板每小时更新，阅读本文时数据可能已变化。由于 GitHub Actions 的数值过大导致其他条形不可见，我们已将其从图表中移除。

实时条形图：按调度器中位偏差（毫秒）从低到高排序，GitHub Actions 因数值过大被排除

截至 7 月 31 日，整点后中位偏差（毫秒）。打开实时看板查看最新数据和方法论。

数据解读

Posthook 以 656 毫秒 的中位偏差最接近目标，随后是 Runhooks 的 749 毫秒。QStash 和 Smpl Jobs 基本持平，偏差约 1.5 秒。EasyCron、Google Cloud Scheduler 和 cron-job.org 则稳定在请求时间后约 4 至 8 秒 内触发。

调度器偏差折线图（GitHub Actions 因数值过大被排除）：最紧凑的线条紧贴零点，多条位于零点上方数秒处，一条平直线位于约 26,500 毫秒，另一条保持约 33,000 毫秒，并在最后几小时跃升至约 51,000 毫秒

截至 7 月 31 日上午的四天到达记录，每到达一次记录一个点，GitHub Actions 因数值过大被排除。

有趣的是，AWS EventBridge 几乎总是晚到 26.5 秒。我们记录的所有到达时间都落在几百毫秒的窄带内，你可以根据它晚到的精确程度来对表。公平地说，EventBridge 的设计目的是大规模分发事件，而它在这方面表现良好。

Cloudflare Workers 也持续晚到：通常在整点后约 33 秒——尽管本周部分运行漂移至 51 秒。我们原本以为其请求可能从未离开自身网络，但它仍晚到 33 秒，因此不存在主场优势。

调度器偏差统计表（毫秒）：平均值、中位数、最小值、最大值、p95、p99 和运行次数，按中位数排序，包含 GitHub Actions

截至 7 月 31 日，所有参赛者的最小值、最大值和百分位（包含 GitHub Actions）。单位仍为毫秒。

GitHub Actions 的中位偏差约为 27 分钟，这已是宽松的估计。超过一半的时间，GitHub Actions 甚至没有触发。公平地说，GitHub 对此已有说明：计划工作流被 记录为尽力而为，在负载高时会被延迟或丢弃。他们没有说错。你无需相信我们的话：我们使用的 [工作流是公开的（https://github.com/smplkit/benchmarks/actions/workflows/cron-skew.yml），GitHub 自己的执行记录也可在 Actions 标签页中查看——包括每小时因运行未发生而出现的空白。

我们不是第一名——对此我们没问题

当我们看到自己的调度器数值持续晚到约 1.5 秒时，我们分析了代码，寻找可能的优化点。我们尝试让它提前一点启动；既然我们一直晚 1.5 秒，为什么不提前 1.4 秒启动呢？但我们并不总是晚 1.5 秒。“提前启动”的策略导致我们有时会提前几毫秒触发，我们认为这可能比晚 1.5 秒更糟。因此我们放弃了提前启动策略，决定让结果自然发生。我们会继续努力改善数值，但与此同时，只有 Posthook 最差的一次运行优于 我们最差的一次运行，这已经算不错了。

但不要只听我们说

我知道，我知道。由 smplkit 创建的基准测试，托管在 smplkit 创建的网站上，结果恰好显示 Smpl Jobs 是“准时”任务调度器中的佼佼者之一。我们知道这看起来如何。但这正是我们创建 smplmark.org 的原因。世界上任何人都可以创建账户并重复我们所做的事。如果需要帮助，请发送邮件至 [email protected]。

你应该在意吗？

任何能在计划时间后几秒内触发的任务调度器，对大多数团队来说可能就足够了。我们测试的 10 款调度器中有 9 款会在计划时间后 60 秒 内触发，其中 7 款会在 10 秒 内触发。但如果追求最准时的执行，Posthook、Runhooks、Smpl Jobs 和 QStash 通常会在请求时间后几秒内触发。

但“准秒”触发只是考虑因素之一。如果你关心响应捕获、运行历史、时区、重试策略和 SDK，请查看 2026 年最佳 cron 任务服务。