标签：Node Web 请求 Storefront js Dynatrace 响应 jsapps 服务器

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 个的话，不建议一次性从数据库中完成全部的数据读取操作。一种更优的解决方案是，采用批量操作 + 游标的方式，从数据库中读取数据。

标签：Node,Web,请求,Storefront,js,Dynatrace,响应,jsapps,服务器
来源： https://www.cnblogs.com/sap-jerry/p/16648936.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。