共计 853 个字符，预计需要花费 3 分钟才能阅读完成。
当以服务器端渲染模式运行的 Web 利用的 Node.js 过程遇到内存透露问题时，通常咱们可能察看到留神到频繁的内存峰值和 pod 重启，如下图 Dynatrace 工具所示：
剖析内存透露问题的要害是在不同的工夫点收集多个内存转储(Memory Dump)，并比拟每个收集之间的对象增长，例如 在 Pod 重新启动后不久和内存饱和之前不久。
能够在 Chrome 中从浏览器开发工具 > 内存（应抉择堆快照）> 加载进行 Memory Dump 的收集和加载操作。
在不同的时间段内进行 Memory Dump 创立之后，就可能应用嵌入式比拟工具疾速辨认两个工夫点之间增长最多的对象。
应用 Chrome 查看工具，能够连贯到远程目标并实时察看内存应用状况。如果内存透露问题能够在本地重现，那么能够依照对运行在本地的 Storefront 进行调试。
在调试模式下运行 Node.js 应用程序，拜访 chrome://inspect，如果在端口转发中配置了 localhost:9229，那么此刻应该可能看到应用程序并对其进行调试。
在 JS Storefront 应用程序中导致内存透露的一种最常见的谬误是是订阅事件而不在组件被销毁后勾销订阅。上面是一个避免这种内存透露的示例——关键在于查看代码并确保在 ngOnDestroy() 中勾销任何事件订阅。
当应用 EventService 并遗记从事件源 Observable 登记时，也会产生同样的状况。任何时候应用事件服务，都应该应用 register() 返回的装配函数 (tear down) 来勾销注册。
SSR Caching
在 SSR 模式下运行的 JS Storefront 应用程序中改善内存耗费的最弱小工具之一是 SSR 缓存，有两种办法：
- 不举荐的做法：间接在服务器上缓存渲染的 SSR 页面。在生产环境中不倡议这样做，因为它不能很好地扩大，并且最终须要比不启用 SSR 缓存时耗费更多的内存。
- 举荐的做法：在 CDN 上缓存渲染的 SSR 页面。这能够进步 SSR 利用的性能，因为它将缩小拜访 SSR 服务器的申请数量，同时将预渲染页面的存储到专门为此目标构建的服务器上。
