共计 819 个字符，预计需要花费 3 分钟才能阅读完成。
JavaScript Storefront 应用程序的性能问题的表现形式有多种，最典型的是响应工夫 (response time) 的好转，甚至因为资源耗尽导致的网站齐全宕机。因为 JavaScript Storefront 波及许多组件，因而确定性能问题的本源可能具备挑战性，如下图所示：
一个客户申请发送到 JavaScript Storefront 之后，Storefront 利用对该申请的解决，将波及以下组件，所有这些都可能是问题的本源：
- 客户端（浏览器或 CDN）
- Apache Web 服务器（通过 JS Storefront vhost），也就是 Commerce Cloud 反对的 redirect endpoint 性能的实现
- Nginx Web 服务器（jsapps pod 的 jsapps 容器）
- Server.js（jsapps pod 的 jsapps-ssr 容器 – 仅在启用 SSR 模式时相干）
- CDN（下面没有阐明，然而如果应用 CDN，那么它将位于此级别 – 如果未找到缓存的响应，申请能够在此处完结或持续到源服务器）
- Apache Web 服务器（通过 API vhost）
- 商务网络服务（API pod）
- 数据库
个别状况下，咱们能够从 Dynatrace 的 Services 面板开始，这里能看到不同类别的服务的均匀响应工夫，最慢的响应工夫，以及每分钟解决的申请数量。
作为性能剖析的切入点，咱们能够从利用响应用户申请的最外层服务开始动手，单击右侧的服务列表中的 ... 符号。
下图的含意是，设置过滤器的值为 响应工夫 >= 6s, 这将容许仅可视化最慢申请的响应工夫热点。
另外留神，Promise.all 这个 API，如果应用不失当，也可能带来性能问题，特地是用大量的操作调用它的时候。
例如，咱们有一个 ids 数组，须要从数据库中依据 id 读取实体。如果列表中有 10 个 id，那不是问题，但如果有 1000 个的话，不倡议一次性从数据库中实现全副的数据读取操作。一种更优的解决方案是，采纳批量操作 + 游标的形式，从数据库中读取数据。
正文完