北京
Cloudflare 给 Workers 和 Durable Objects 上线了按需 CPU 与内存性能分析（profiling）功能。开发者可以在生产环境中直接抓取已部署版本的性能数据，通过交互式火焰图定位瓶颈，不必再只靠日志和聚合指标猜问题出在哪。
这套功能通过 Workers Observability 仪表盘或 cf CLI 触发，支持把结果下载下来做离线分析。火焰图里区块越宽，说明对应函数占用的 CPU 时间或采样到的内存分配份额越大。
它和本地调试工具的关键差别在于：分析针对的是一个已经在运行的 isolate，而不是新起一个。也就是说，看到的是真实生产流量下的代码行为。Durable Objects 还多一层支持——可以指定某个具名实例做分析，适合排查和有状态负载绑定的问题。
限制也写得很清楚：目标在抓取窗口内必须收到足够流量；TypeScript 开发者应开启 source map，函数名才好看懂。
分布式边缘带来的工程难题
Workers 跑在 Cloudflare 的分布式边缘基础设施上，一个脚本可能在多个数据中心、多台物理机上存在多个 isolate。一次分析请求因此要先定位到指定的 Worker 版本，再找到一个合适的活跃 isolate。
Durable Objects 更难一层：它有状态，还会在位置之间迁移，所以分析请求会被路由到承载该对象的那台机器上。
抓取期间运行时并不会一直持有 isolate 锁。CPU 分析会启动一个按1 毫秒间隔采样的 V8 profiler，随后释放锁让请求继续执行，结束时再重新获取锁、停止分析并收集结果。这样平台能观察真实执行，又不会在抓取期间挂起正常的请求处理。
CPU 和内存回答的是两个问题
CPU 分析采样调用栈，揭示执行时间花在哪里，用来找昂贵函数、重复计算和优化空间。内存分析则聚焦函数相关的分配，帮开发者找出大量创建对象、推高内存压力的代码。
诊断时这个区分很实际：一个函数可能吃掉大量 CPU 却几乎不分配内存，另一个可能分配很多但不主导执行时间。看对哪种 profile，才能把排查范围收窄到真正的瓶颈资源上。
Cloudflare 自己内部就用这套功能找过问题。对一个 R2 绑定的 Worker 做分析，发现一个递归的 JSON replacer 反复遍历嵌套数据，让函数做了大量重复工作。修正实现后，官方称速度快了2.7 倍。另一次分析则暴露出一处多余的重复指标调用，约占1% 的 CPU 时间。
内存分析还揪出另一个问题：部分被禁用的 Prometheus 埋点据称仍在占用可观内存。Cloudflare 称，删掉剩余代码后，该 Worker 的 99.9 分位内存使用从 133 MB 降到 118 MB，回到了 128 MB 限制线以下。
补位而非替代
这套能力和现有工具是互补关系。Chrome DevTools 支持本地 CPU 分析，开发阶段好用，但复现生产流量和数据并不容易。pprof 在 Go 等分析流程里被广泛使用，离线分析能力强，Cloudflare 也允许把下载的 profile 交给 pprof 查看。它的差异点在于，能通过平台已有的运维界面，直接对运行中的 Workers 和 Durable Objects 发起分析。
它同样和日志、指标、分布式追踪互补：后三者帮你发现服务什么时候变慢、资源什么时候吃紧，profile 则帮你指到具体是哪个函数。
需要分清的是，按需抓取不等于持续监控。短窗口可能漏掉间歇性问题，堆分析记录的是抓取期间的分配情况，而不是保留内存的全貌。Cloudflare 表示正在推进持续分析，那样排查偶发性能问题就不必先掐准它什么时候发生。
对在生产环境跑 Workers 的团队来说，这次发布补上的是一段实际能力：从发现资源压力，走到定位负责的代码，中间不必先在本地复现问题。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
