生产系统运行的企业级JavaScript应用性能问题分析指南运行时失败或异常的根源就这么简单。JavaScript应用程序的性能问题往往表现为用户请求响应时间的下降，系统可用资源的减少甚至耗尽。本文以开源电商Storefront企业应用Spartacus为例，分享当JavaScript应用在生产系统中遇到性能问题时，开发者应该如何分析可能的原因。当用户在浏览器中发起对Storefront的访问请求时，会经过以下组件处理。所以理论上，所有这些组件都可能是性能问题的根源。负载均衡服务器运行JavaScriptStorefront的WebServer（如Nginx、Apache）Server.js：JavaScriptStorefront以服务端渲染方式运行，实现CDNAAPI服务器数据库。我们可以使用Dynatrace这个强大的平台来分析JavaScript应用程序的执行性能数据。Dynatrace中的服务菜单是开始分析的推荐入口点，因为可以在此处查看上述所有组件的性能数据。可视化所有组件及其响应时间贡献的推荐方法是，如果可能的话，从调用的最外层开始，即运行与网站对应的Apache服务的JavaScriptStorefront，在本例中为www.demo.com:443。单击右侧的图标...并选择服务流。在接下来的页面中，最好将分析时间缩小到存在明显性能问题的时间窗口。另一种方法是添加一个响应时间过滤器，只关注那些响应时间最慢的请求。例如，设置过滤器响应时间>=6s将允许仅可视化那些响应时间等于或大于6秒的请求热点。需要强调的是，ServiceFlow图中显示的每个节点都依赖于前一个节点，所以在分析一段时间的性能数据时，相邻几个节点的响应时间百分比通常都很高，直到一个真正的Services到目前为止的性能问题。例如，如果性能瓶颈是数据库，那么它之前的所有层也会对整体贡献做出贡献，即使它们只是简单地等待数据库操作完成。例如，在上面显示的场景中，瓶颈似乎是Node.js应用程序，因为响应时间的百分比下降发生在这个Node.js应用程序之后。单击任何层并使用...按钮，选择ResponseTimeHotspot选项，可以查看每个级别的个人贡献者。例如，从www.demo.com:443开始，我们发现一个特定请求对总体响应时间百分比的贡献最大。由于我们怀疑性能问题是Node.js应用引起的，我们可以进一步查看jsapps的性能数据，如下图所示，它的CodeExecution耗时6.19秒。点击上图中的CodeExecution进入详情页面，然后重复点击...继续查看，直到找到对6.19s响应时间贡献最大的那一行函数调用。
