运行在 CCV2 环境上的 Spartacus Storefront 如果出现性能问题该怎么分析

理论上来说，一旦用户请求到达 Spartacus SSR 服务器，通常有三个潜在的响应时间贡献者，其中最后一个也可以细分成多个潜在的性能瓶颈：

• 执行 Node.js 代码所花费的时间
• 在 apache 层上向 OCC 层请求所花费的时间
• 请求 OCC 层在 API 服务器上花费的时间

对于第三点，下列原因都可能造成 API 服务器响应时间过长：

• API pod 上的资源耗尽
• DB 锁定/DTU 耗尽
• 对公共网络的请求（例如 payment 提供商）
• 线程/资源锁定和争用
• 代码执行

如果发现代码执行是响应时间的主要贡献者，接下来的调查应该集中在 Node.js 代码和 SSR 服务器资源利用率上。

如果最大贡献者是 OCC 请求，则可以重复上述相同步骤，以确定这些请求中最慢的最大贡献者。 例如，使用 api-demo.com:443 层的响应时间分析，将有助于了解绝大部分响应时间，到底是花费在 API 服务器、数据库还是对公共网络的请求上。

在此示例中，我们将从 www.demo.com:443 开始，然后单击 PurePaths. 在随后的单个请求分析中，添加响应时间过滤器，以仅保留响应速度最慢的子请求，有助于我们把调查精力放在真正的性能瓶颈上。

单个请求的 PurePaths 将显示在代码或 apache 上花费的任何时间以及每个数据库查询和对外部系统的调用。 当我们有兴趣准确了解瓶颈在哪里时，这个功能极其有用，甚至可以深入到单个的数据库查询。 不足之处是 PurePaths 一次只能查看一个请求。

从上面可以清楚地看出，至少对于我们选中的特定的请求来说，时间几乎完全花在了 Node.js 代码的执行上。这提示我们，需要检查一下 jsapps pod 上的 CPU 和内存利用率。

资源利用率的分析会根据使用 CSR 或 SSR 模式而略有不同。

在这两种情况下，Dynatrace 会显示相对于 VM 的 CPU 使用率。 例如，如果一个 pod 有 8 个内核，而 VM 有 16 个内核，当 Dynatrace 显示 CPU 为 50% 时，它实际上表示 CPU 为 100%。

当 Spartacus 工作在 CCV2 的 CSR 模式下时，CSR 容器本质上只是一个将请求路由到 OCC 层的 nginx Web 服务器。 在选择 Nginx 和 nginx jsapps-* 后，可以从 Dynatrace 的技术和进程页面中查看 CPU 和内存使用率。

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

如果发现 CPU 或者内存利用率过高，通常表明 CCV2 Pod 没有足够的副本来处理所有请求，因此水平扩展将是一种可能的解决方案。