为什么GraphQL性能监控很难 - Marc-AndréGiroux

衡量API性能对于实现正确性非常重要，而对于GraphQL也是如此。实际上，有些人可能因为性能问题而使用GraphQL，并用一个GraphQL调用替换多个调用。但是你的GraphQL查询实际上更快吗？这就是监控它们的重要性。
如果您已习惯基于端点的HTTP API，则可能之前已成功完成某些监视。例如，监控API性能的最基本方法之一是测量响应时间。
不幸的是，我们很快发现，测量GraphQL端点的响应时间几乎不能让我们深入了解GraphQL API的运行状况。让我们看一下超简化的例子。想象一下，您维护一个当前提供简单查询的GraphQL API：

query {
  viewer {
    name
    bestFriend {
      name
    }
  }
}

现在，一个新的API客户端开始使用我们的GraphQL API，但是不同的更大的需求：

query {
  viewer {
    friends(first: 1000) {
      bestFriend {
        name
      }
    }
  }
}

第二个实际上是请求超过一百个对象，而第一个只查询一个对象。如果您正在监视GraphQL端点，您会看到响应时间大幅增加。这是因为我们返回的响应确实有点慢，因为我们提供了更复杂的查询！
如果您正在管理公共API，或者使用大量客户端和查询的非常大的内部API，由于查询的基数较高，监控性能可能并不容易，隐藏在其中。然后我们必须找到其他方法。

一种常见的方法是将我们的思维方式从监控查询转变为监控解析器，其中计算单个字段。然后我们可以快速查看字段是否表现缓慢。这种方法存在一个主要问题，这使得使用这种方法很难准确地监控GraphQL API的性能：延迟/批量加载

我们如何确定GraphQL端点的响应时间对于特定查询来说是否太慢。可以构建类似于慢查询日志的东西，以帮助工程师找出哪些查询运行缓慢。

是否能找到查询复杂性和查询执行时间之间的关系。如果我们发现它们以特定方式相关，我们理论上可以检测到异常。例如，具有高执行时间的低复杂性查询可能表示我们需要仔细查看查询的执行情况。

大规模的GraphQL监控真的很难。现在没有太多工具可以帮助我们解决这些问题，但我希望我们能够探索更智能的方法来深入了解GraphQL的执行性能，敬请期待！