运行在 CCV2 环境上的 Angular 服务器端渲染应用的性能瓶颈分析

举报
Jerry Wang 发表于 2022/11/30 10:23:56 2022/11/30
【摘要】 本文分析笔者在项目中开启 Angular 应用的服务器端渲染模式后,遇到性能问题时的分析思路和最终的解决方案。

本文分析笔者在项目中开启 Angular 应用的服务器端渲染模式后,遇到性能问题时的分析思路和最终的解决方案。

在 Angular 应用程序中使用服务器端渲染,出于以下几种原因:

  1. SSR 有助于搜索引擎优化。 搜索引擎爬虫可以解析通过服务器端渲染的 HTML 页面源代码。而运行在 CSR 模式下的单页面应用,页面源代码是在客户端浏览器里执行复杂的 JavaScript 生成,现代很多爬虫对此内容无能为力。

  2. Facebook 和 Twitter 等社交媒体平台,可以在共享时显示 SSR 渲染出的网站的预览。

  3. 在服务器上呈现网页后,页面内容可以被缓存,从而能够更快的响应用户相同的页面请求。

要在 Angular 应用程序中实现服务器端渲染,可以使用 Angular Universal package.

当我们使用 Angular Universal 时,向 OCC 服务器发起业务数据请求的 API 触发两次。首先是在服务器渲染页面时实行一次,第二次是在客户端应用程序启动时触发。这种 API 重复触发的方式会导致延迟问题和糟糕的用户体验,因为发生这种情况时屏幕通常会闪烁(flickering).

此外,SAP CCV2 上的 SSR 容器是运行 Node.js 代码的地方,因此更容易受到性能下降的影响。在选择 Node.js 和 server.js jsapps-* 之后,可以从 Dynatrace 中的技术和进程页面查看 CPU 和内存。注意 SSR 应用文件的名称可能不同,默认为 main.js.

随后的页面将显示所选任何给定指标的平均利用率。 单击单个 pod 将进入其进程详细信息页面,其中可以查看有关 cpu/内存利用率和重新启动时间的信息。 对于 SSR,有关 CPU 的详细信息将在系统性能选项卡下,而有关 V8 内存使用的详细信息将在 Node.js 指标选项卡下。

当发现 SSR Pod 的 CPU 利用率居高不下时,基于 Node.js 的设计,尽管我们可以通过垂直扩展来缓解这个问题, 另一方面,如果并发请求的数量很大,那么也可以考虑通过水平扩展的方式来降低每个 Pod 的 CPU 利用率。

尽可能多地消除 Spartacus Storefront 中 CPU 密集型代码 ,必要时可以研究是否能够将逻辑转移到 OCC 层执行。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200