【发布时间】：2022-06-12 05:26:54
【问题描述】：
我们面临着一些具有挑战性的性能问题，一些查询需要很长时间才能响应，通常超过 20 秒，并且经常在 60 秒时超时。即使使用像 graphql-bench 和 autocannon 这样的负载测试工具，这些极端时间也无法在本地开发环境中重现。这些相同的查询也可以在大约 500 毫秒内完成。
我们有一个联合图设置，其中包含一个 Apollo Gateway 实例（运行 ~0.24）和 2 个 Apollo Server 实例（运行 3.x）提供子图。所有 3 个都在 Apollo Server + express 之上使用 NestJS 7。我们的解析器使用 Typeorm 与相当大且复杂的 MSSQL 数据库进行交互。数据库是巨大的 OP，资源监视器永远不会超过 10% 的 RAM 和 CPU。
API 服务器托管在 AWS ECS 上，资源丰富。与 DB 服务器一样，CPU 和 RAM 使用率平均为 10-20%，尽管 CPU 有时会飙升至 >100%。
Apollo Studio 中的跟踪似乎显示一些高级解析器“挂起”或“等待”很长时间。 IE。 30 秒响应中的 27 秒。
我们确实有一些 N+1 问题，我们在一些地方有限地使用 Dataloader 来解决这些问题，尽管我们肯定可以更多地实施它。我不相信 N+1 问题是造成极端时机的原因，尽管由于这些时机的范围很广并且它们的不一致。
这个场景对任何人来说都很熟悉吗？有没有人有任何想法或指示我们如何追踪根本问题并调试它？我们有点难过，尤其是这些问题似乎无法在本地重现。
【问题讨论】：
-
@W.S. ，抱歉，我可能不清楚：CPU 峰值不是来自数据库服务器，而是来自运行网关和子图的 ECS 任务。据我所知，数据库服务器几乎没有出过汗。一些额外的信息：在高峰时间，图表的吞吐量最大约为 400rpm。网关服务器在 ECS 中有 6 个实例，而有问题的主要子图服务器有 9 个实例。很可能超过顶部，但减少该数字对响应时间有明显的负面影响
标签： node.js graphql nestjs typeorm apollo-server