联邦GraphQL API的负载测试
使用GraphQL进行负载测试的注意事项
当涉及到对GraphQL API进行负载测试时，其过程与其他类型的API类似，大部分考虑因素也将保持不变。然而，在进行负载测试之前，有一些针对GraphQL和Apollo生态系统特定的区别是值得注意的。
需要注意的是，本文的目的在于引起人们对使用GraphQL进行负载测试的独特考虑的关注，而不是作为关于GraphQL负载测试设置和执行的全面指南。
需要加载测试的内容
当测试GraphQL API的负载时，有两种主要的测试运行方式：
- 测试整个已部署的应用程序堆栈
- 单独测试每个已部署的服务
这两种方法都有其优点和权衡。对服务进行孤立测试允许您独立测试每个服务的极限，并为每个独立服务提高性能提供有价值的参考资料。然而，这也许不能提供有关如何集中精力以最大程度影响最终用户体验的见解。进行全栈测试更适合查找这类瓶颈，但可能对其他服务的极限了解不多。我们建议关注对服务进行孤立测试，以最大程度地了解不仅当前的瓶颈，还有潜在的瓶颈。这并不意味着应该避免全栈测试，因为它们也有其位置。
使用可观察性工具进行性能洞察
字段级性能指标每项操作等。
由于收集跟踪数据可能会对性能产生明显影响，因此在测量峰值负载时请考虑关闭跟踪进行测试。在负载测试期间启用跟踪将有助于阐明您的图的哪些部分运转缓慢，以及哪些解析器可以进行优化。关于跟踪性能考虑的文档更详细地介绍了如何修改跟踪行为。路由器可以发射处理请求所花费时间的指标，等待外部或子图请求之外。结合路由器和跟踪指标，负载测试之后提供大量的细节来诊断性能问题。
Apollo为发送指标至任何支持Open Telemetry（OTLP）协议的系统提供一流支持，同时为企业客户提供内置的Datadog集成。Open Telemetry协议的系统外提供了首位支持和GraphOS Studio
不要污染生产指标
在生产的图上执行负载测试时，请排除负载测试指标从实时生产指标中。对于发送到GraphOS的指标，考虑发送负载测试流量到专用模式My-Graph@load-variant。这将允许您干净地将生产指标与负载测试分开。
💡 提示
根据需要，考虑排除系统其他部分的负载测试指标。
使用类似于生产使用的实际负载模式
如果负载测试结果与生产流量的模式非常接近，那么它们最有用。例如，只有一个预定义数量的内部客户端应用的图。如果实际操作数比这个数量低几个数量级，那么在负载测试中生成200,000个唯一操作就没有意义。在负载测试期间模拟现实模式对于确保结果与性能改进相关且有用非常重要。此外，考虑测试不同的场景，如峰值使用、意外的流量激增和长期使用模式，以确保GraphQL API可以处理各种类型的负载。
潜在瓶颈
性能瓶颈可能出现在应用级别（解析器和更远），而不是在router或GraphQL执行引擎中。当我们为路由器的早期alpha版本创建了第一个负载测试时，我们必须创建测试套件来针对路由器和网关运行。要使用现实负载模式完全触及网关的瓶颈，我们必须从子图中去除几乎所有的延迟。对于大多数实际情况，花在子图解析器代码和底层数据源上的时间将是瓶颈。你会在这些层看到性能降级的情形通常是当唯一操作数量很高时。
操作基数
当GraphQL API遇到一个新操作时，该操作必须被解析成适当格式，与现有模式进行验证，然后最终执行。router还会进行额外的查询计划步骤。如果唯一操作数量足够高，这些步骤可能会造成明显的运行时开销和延迟。这些步骤必须发生在你的图上针对每个唯一操作的初始请求。
这些步骤中的大多数都可以高度缓存。Apollo 有几个内置功能可以充分利用这一点，例如 自动持久性查询（APQ）。 APQ 默认在 Apollo Server/Gateway 和 GraphOS Router 中启用，只需在 Apollo Client 中进行简单的配置设置即可启用它们。只能执行一次的高基数操作无法利用这些特性中的大多数。由于操作通常执行多次，这在大多数实际应用中并不是一个大问题。