Cloudflare Workers 处理函数计算中的 CPU 性能问题
<p>原文: <a href="https://blog.cloudflare.com/unpacking-cloudflare-workers-cpu-performance-benchmarks/">https://blog.cloudflare.com/unpacking-cloudflare-workers-cpu-performance-benchmarks/</a></p> <p>原文主要讲述了 Cloudflare Workers 和 Vercel 在 CPU 性能方面的一些对比, 在应用上的重点是 React SSR 类应用的 TTFB 测试.</p> <p>其中我认为的一些关键点是:</p> <ol> <li>函数计算的调度问题 (非 CPU 计算消耗).</li> <li>Node.js 对 V8 调参导致的性能问题.</li> <li>代码中处理 buffer 不当导致的内存占用及后续 GC 的问题.</li> <li>Node.js 的非 Web 标准化问题, 比如 Streams API.</li> <li>Cloudflare Workers 团队在解决自己问题的过程中如果发现了生态问题, 甚至竟品问题, 也期望一并解决.</li> </ol> <p>我们的核心业务均由函数计算承担, 在此处有许多经验. 函数计算中的几大时间消耗为:</p> <ol> <li>调度时间</li> <li>(可能) 冷启动时间</li> <li>执行时间 (被计算为 CPU 消耗)</li> </ol> <p>一般来说, “执行时间” 与函数计算无关. 函数计算需要重点考虑的, 是 “调度时间” 和 “冷启动时间”.</p> <p>作为用户, 一些配置会影响到调度时间, 比如使用什么操作系统, 是否要接入 VPC 等.</p> <p>想要优化冷启动时间, 则应该将重点放在 “架构” 上. 一般来说, 解释型语言的冷启动时间会小很多. 比如函数计算一般使用 Python, JavaScript, 而不使用 Java.</p> <p>另外一种优化就是 “预热”, 可以理解为提前启动. 但是预热是有成本开销的, 并且我认为预热是有悖于函数计算模式的. 我更倾向于减少冷启动时间, 而不是预热.</p> <p>Cloudflare Workers 针对调度问题的优化, 是所有用户乐于看到的. 加量不加价, 并且默认生效, 用户无需任何额外配置.</p> <p>Node.js 的非 Web 标准化问题, 就是我们几年前选型 Deno, 而非 Node.js 的关键原因. 即便我们不是全栈团队, 也希望在 JS 领域, 技术栈尽量统一, 减少不必要的消耗.</p> <p>最后, 看到问题就想要去解决, 无论这个问题是否影响到自身利益, 这不仅是工程师应该有的素质, 也是每一个人应该有的素质. 就像走路时如果看到了脚边的垃圾, 可以顺手捡起来扔到垃圾箱中.</p> <p>不是鼓励大家无偿奉献, 而是举手之劳, 何乐而不为? 每个人多付出 1%, 就会让整个世界进步不只 100%.</p>