关于ssr:运行在-SSR-模式下的-Angular-应用的内存泄漏问题分析

33次阅读

共计 1523 个字符，预计需要花费 4 分钟才能阅读完成。

运行在 SSR 模式下的 Angular 利用，为了防止服务器端和客户端两次调用同样的 API 引起屏幕的 Flickering 问题，通过都会应用 Angular TransferState 服务将信息从服务器发送到客户端，其工作原理如下图所示：

首先在应用程序 app.module.ts 中导入 BrowserTransferStateModule：

import {BrowserModule, BrowserTransferStateModule} from '@angular/platform-browser';
imports: [BrowserModule.withServerTransition({appId: 'my-app'}),
  BrowserTransferStateModule,
  ...
]

而后在服务器端模块 app.server.module.ts 中导入 ServerTransferStateModule：

import {ServerModule, ServerTransferStateModule} from '@angular/platform-server';
imports: [
  AppModule,
  ServerModule,
  ServerTransferStateModule,
  ...
]

咱们能够应用 makeStateKey 函数来创立一个键，以存储状态中的数据（将传递给浏览器）。应用 this.state.get 从状态中获取数据，并应用 this.state.set 设置状态中的数据。进行 API 调用时，应用之前调用 makeStateKey 创立的密钥将返回的数据存储在 Angular state 中。

采纳了 TransferState 服务的 Spartacus SSR 利用，在呈现内存透露时通常有下列体现：

用户申请响应工夫减少
jsapps pods 频繁重启
运行时呈现如下日志：

(1) SSR rendering exceeded timeout 3000, fallbacking to CSR for /xyz
(2) PM2 Process 0 restarted because it exceeds –max-memory-restart value (current_memory=4009730048 max_memory_limit=3865051136 [octets])
(3) Rendering of /xyz was not able to complete. This might cause memory leaks!

如果呈现了以上之一的症状，咱们能够应用 Dynatrace 进行内存透露起因剖析。

在 Dynatrace 中，能够从左侧导航菜单中的技术和过程选项和 Node.js 技术中找到每个 SSR pod。过程组将具备蕴含您的应用程序 SSR 的主文件的名称，通常是 main.js 或 server.js。单击后者将列出在指定工夫范畴内处于活动状态的 pod，容许咱们拜访任何单个 pod 的过程详细信息页面。

在 high level 层面，仅通过查看 Dynatrace 中的 V8 堆内存图表就能够对内存透露的可能性做出理智的判断。Node.js 中潜在内存透露的最显著迹象是：