news view

Cloudflare Workers 处理函数计算中的 CPU 性能问题

原文: https://blog.cloudflare.com/unpacking-cloudflare-workers-cpu-performance-benchmarks/

原文主要讲述了 Cloudflare Workers 和 Vercel 在 CPU 性能方面的一些对比, 在应用上的重点是 React SSR 类应用的 TTFB 测试.

其中我认为的一些关键点是:

  1. 函数计算的调度问题 (非 CPU 计算消耗).
  2. Node.js 对 V8 调参导致的性能问题.
  3. 代码中处理 buffer 不当导致的内存占用及后续 GC 的问题.
  4. Node.js 的非 Web 标准化问题, 比如 Streams API.
  5. Cloudflare Workers 团队在解决自己问题的过程中如果发现了生态问题, 甚至竟品问题, 也期望一并解决.

我们的核心业务均由函数计算承担, 在此处有许多经验. 函数计算中的几大时间消耗为:

  1. 调度时间
  2. (可能) 冷启动时间
  3. 执行时间 (被计算为 CPU 消耗)

一般来说, “执行时间” 与函数计算无关. 函数计算需要重点考虑的, 是 “调度时间” 和 “冷启动时间”.

作为用户, 一些配置会影响到调度时间, 比如使用什么操作系统, 是否要接入 VPC 等.

想要优化冷启动时间, 则应该将重点放在 “架构” 上. 一般来说, 解释型语言的冷启动时间会小很多. 比如函数计算一般使用 Python, JavaScript, 而不使用 Java.

另外一种优化就是 “预热”, 可以理解为提前启动. 但是预热是有成本开销的, 并且我认为预热是有悖于函数计算模式的. 我更倾向于减少冷启动时间, 而不是预热.

Cloudflare Workers 针对调度问题的优化, 是所有用户乐于看到的. 加量不加价, 并且默认生效, 用户无需任何额外配置.

Node.js 的非 Web 标准化问题, 就是我们几年前选型 Deno, 而非 Node.js 的关键原因. 即便我们不是全栈团队, 也希望在 JS 领域, 技术栈尽量统一, 减少不必要的消耗.

最后, 看到问题就想要去解决, 无论这个问题是否影响到自身利益, 这不仅是工程师应该有的素质, 也是每一个人应该有的素质. 就像走路时如果看到了脚边的垃圾, 可以顺手捡起来扔到垃圾箱中.

不是鼓励大家无偿奉献, 而是举手之劳, 何乐而不为? 每个人多付出 1%, 就会让整个世界进步不只 100%.

- Cloudflare Workers - 函数计算
iugo
This site is open source. Improve this page.