Heroku部署Node应用响应耗时为本地10倍是什么原因？

首先明确两个场景的耗时成因，对应排查配置和优化方向：

休眠状态1-2s响应的成因 #

Heroku免费层、基础层dyno默认配置为30分钟无传入请求就会进入休眠状态，休眠状态下实例会被回收资源，下次请求触发时需要重新完成实例调度、Node进程拉起、依赖加载、数据库连接初始化全流程，1-2s的唤醒耗时是该档位实例的正常表现，不属于配置遗漏。

唤醒后仍有500-600ms响应（对比本地50ms）的排查优化点 #

• 先确认dyno规格：免费层dyno的CPU、内存为多租户共享资源，算力本身远低于本地开发机，资源争抢带来的性能损耗通常在2-5倍区间，对延迟有要求的场景升级为标准版专用dyno，可以直接消除共享资源带来的基础性能差。
• 校验生产环境启动配置：确认部署时启动命令正确设置了生产环境变量，不加载开发依赖，避免无关调试、测试工具占用运行时资源。标准生产启动命令参考：

  NODE_ENV=production node your-entry-file.js
  

  注意不要用nodemon、ts-node-dev这类开发态热启动工具跑生产服务。
• 排查跨服务网络开销：本地环境下应用和数据库、缓存、第三方接口的网络链路延迟通常在1ms以内，Heroku部署时如果数据库、缓存实例和应用不在同一可用区，单次网络往返就会增加100-300ms的固定延迟；另外确认生产环境是否配置了数据库连接池，禁止每次请求都新建数据库连接。
• 检查运行时冗余逻辑：确认生产环境关闭了debug级别的全量日志打印，不要在请求处理链路中做同步的大体积日志写入、文件读写操作；如果有静态资源返回逻辑，不要让Node.js进程直接处理静态资源请求。
• 平台固有开销说明：Heroku在应用进程前默认挂载了全局路由反向代理层，这一层本身会带来20-100ms的固定转发延迟，属于平台架构固有开销，无法通过应用配置消除。
• 休眠规避方案：如果不能接受冷启动的1-2s延迟，可以配置定时任务每10-20分钟向应用发送一个轻量心跳请求，维持dyno不进入休眠。注意免费层dyno有月度运行时长配额限制，开启心跳会快速消耗配额。

内容的提问来源于stack exchange，提问作者Nikhil Mandaliya