共计 1161 个字符，预计需要花费 3 分钟才能阅读完成。
企业级 JavaScript 利用部署在生产零碎并运行后，如果呈现性能问题，则找出引起这些性能问题的本源，往往不像找出引起运行时故障或者异样的本源那么简略。JavaScript 利用的性能问题往往体现在用户申请响应工夫的降落，零碎可用资源的升高甚至耗尽。
本文以一个开源的电商 Storefront 企业级利用 Spartacus 为例，来给大家分享 JavaScript 利用在生产零碎遇到性能问题时，开发人员应该如何去剖析可能的起因。
当用户在浏览器里发动一个对 Storefront 的拜访申请之后，会经由下列组件进行解决。因而从实践上讲，所有这些组件都可能成为导致呈现性能问题的本源之一。
- 负载平衡服务器
- 运行 JavaScript Storefront 的 Web Server(比方 Nginx，Apache)
- Server.js：JavaScript Storefront 运行在服务器端渲染模式下的实现
- CDN
- API 服务器
- 数据库
咱们能够应用 Dynatrace 这个弱小的平台来剖析 JavaScript 利用的执行性能数据。Dynatrace 中的服务菜单是开始性能剖析的举荐入口，因为这里能看到上述所有组件的性能数据。
可视化所有组件及其响应工夫奉献的一个举荐的办法，是尽可能从调用的最外层开始，即 JavaScript Storefront 运行网站对应的 Apache 服务，在本例中为 www.demo.com:443.
单击右侧的图标 ... 并抉择 Service Flow. 在随后显示的页面中，最好将剖析工夫的范畴放大到有显著性能问题的工夫窗口。另一种形式增加响应工夫过滤器，以仅关注响应工夫最慢的那些申请。
例如，设置过滤器响应工夫 >= 6s，将容许仅可视化那些响应工夫等于或者超过 6 秒的申请热点。
须要强调的是，Service Flow 图表里显示的每一个节点都依赖于前一个节点，因而在剖析一个时间段的性能数据时，可能相邻若干节点的响应工夫百分比通常都会很高，直到遇到真正有性能问题的服务为止。例如，如果性能瓶颈是数据库，那么它之前的所有层也都将参加整体奉献，即便它们只是在简略的期待数据库操作的完结。
例如，在上图所示的场景中，瓶颈仿佛是 Node.js 应用程序，因为响应工夫的百分比降落，产生在这个 Node.js 程序之后。
通过单击任何层并应用 ... 按钮，选择响应工夫热点选项，能够查看每个级别的单个贡献者。例如，从 www.demo.com:443 开始，咱们发现一个特定的申请，对总体的响应工夫百分比奉献最大。
既然咱们猜测是 Node.js 利用造成的性能问题，能够进一步查看 jsapps 的性能数据，如下图，其 Code Execution 破费了 6.19 秒。
点击上图的 Code Execution，进入明细页面，再反复点击 ... 持续查看，直至发现对响应工夫 6.19 s 奉献最多的那一行函数调用。
