实践上来说，一旦用户申请达到 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 没有足够的副原本解决所有申请，因而程度扩大将是一种可能的解决方案。