理论上，一旦用户请求到达SpartacusSSR服务器，通常有三个潜在的响应时间贡献者，最后一个也可以细分为多个潜在的性能瓶颈：执行Node.js代码耗时TimespentrequestingOCClayerapachelayerTimespentrequestingOCClayeronAPIserver对于第三点，以下原因可能导致API服务器响应时间太长：APIpodsDB上的资源耗尽锁/DTU耗尽对公共网络（例如支付提供商）的请求线程/资源锁和竞争代码执行.如果顶级贡献者是OCC请求，则可以重复上述相同步骤以确定这些请求中最慢的顶级贡献者。例如，在api-demo.com:443层使用响应时间分析将有助于了解绝大多数响应时间是否花在API服务器、数据库或对公共网络的请求上。在此示例中，我们将从www.demo.com:443开始并单击PurePaths。在后续的单个请求分析中，添加响应时间过滤器以仅保留响应最慢的子请求有助于我们将调查重点放在真正的性能瓶颈上。单个请求的PurePaths将显示在代码或apache中花费的任何时间，以及每个数据库查询和对外部系统的调用。当我们有兴趣准确了解瓶颈所在时，甚至是单个数据库查询，此功能非常有用。缺点是PurePaths一次只能查看一个请求。从上面可以清楚地看出，至少对于我们选择的特定请求，时间几乎完全花在了执行Node.js代码上。这会提示我们检查jsappspod上的CPU和内存利用率。资源利用率分析因使用CSR或SSR模式而略有不同。在这两种情况下，Dynatrace都会显示相对于VM的CPU使用率。例如，如果一个pod有8个内核，而一个VM有16个内核，当Dynatrace显示CPU为50%时，它实际上表示CPU为100%。当Spartacus在CCV2的CSR模式下工作时，CSR容器本质上只是一个将请求路由到OCC层的nginxWeb服务器。选择Nginx和nginxjsapps-*后，可以从Dynatrace的技术和进程页面查看CPU和内存使用情况。后续页面将显示所选任何给定指标的平均利用率。单击单个pod将带您进入其进程详细信息页面，您可以在其中查看有关cpu/内存利用率和重启时间的信息。对于CSR，有关CPU和内存的详细信息位于“系统性能”选项卡下。如果您看到高CPU或内存利用率，通常表示没有足够的CCV2Pod副本来处理所有请求，因此水平扩展将是一个可能的解决方案。
