生产环境AWS Lambda VPC部署下Puppeteer启动极慢问题排查求助

首先可以明确：VPC配置本身不是导致解压变慢的直接原因。Lambda的/tmp目录是执行环境本地的临时存储，executablePath的解压逻辑是纯本地CPU+磁盘IO运算，不涉及VPC网络流量，所以VPC部署不会直接拖慢解压速度。

如果变慢现象和VPC部署同步出现，大概率是和VPC绑定的其他配置差异导致，常见关联原因及优化方案如下：

• 内存配置差异：Lambda的CPU算力、磁盘IO性能都和分配的内存大小正相关，1GB内存对应1vCPU算力。如果公司账号的Lambda内存只配置了256MB或更低，解压性能自然远低于你个人账号更高内存的实例。
  优化方案：将Lambda内存调整到至少1024MB，实测该配置下chrome-aws-lambda解压耗时稳定在3-6秒区间。
• 临时存储配额差异：chrome-aws-lambda解压后的二进制总大小接近150MB，如果公司账号把Lambda临时存储配额设为刚好卡线的大小，会导致磁盘IO被限速，大幅拉长解压耗时。
  优化方案：将Lambda临时存储配额调整到至少512MB，预留足够的IO缓冲空间。
• 执行环境复用未生效：默认Lambda冷启动完成一次解压后，后续热启动请求会直接命中/tmp/chromium存在的判断逻辑，直接返回路径不需要重复解压。如果公司账号的Lambda并发配置不合理，导致每次请求都是冷启动，就会每次都触发完整解压流程。
  优化方案：配置Lambda预并发（Provisioned Concurrency）预留常驻实例，或者调整函数逻辑不要主动清理/tmp下的chromium相关文件，最大化热启动命中率。

如果排除VPC关联的配置差异，你可以从以下方向定位根源：

• 检查依赖版本一致性：确认两个环境的chrome-aws-lambda版本完全相同，不同版本的二进制压缩率、lambdafs解压逻辑都有差异，部分旧版本存在已知的解压效率bug。
• 检查运行时版本配置：你贴的源码里有判断Node.js运行时版本的逻辑，如果公司账号用的Node.js运行时不在10/12/14范围内，虽然不会直接影响解压耗时，但可能触发额外的兼容逻辑拖慢整体执行速度。
• 检查部署包打包逻辑：如果你个人账号用的是serverless框架默认打包，公司账号用了自定义打包/压缩工具，可能导致bin目录下的.br压缩包被二次压缩，运行时需要先解压外层部署包再解压内层的br文件，额外增加耗时。
• 检查Lambda层配置：如果公司账号把chrome-aws-lambda放到了独立的Lambda层（Layer）中，层的加载耗时会叠加到解压步骤上，你可以把依赖直接打包到函数部署包内验证耗时变化。
• 开启X-Ray链路追踪：给Lambda开启X-Ray追踪后可以看到每一步的耗时占比，精准定位是解压逻辑本身耗时高，还是函数初始化阶段的其他步骤卡壳。

内容的提问来源于stack exchange，提问作者m. savantfou