Microsoft Fabric 的 GraphQL API 提供了一种高效查询数据的强大方法，但性能优化是确保流畅且可缩放性能的关键。 无论是处理复杂的查询还是优化响应时间，以下最佳做法都有助于充分利用 GraphQL 实现的最佳性能，并最大程度地提高 Fabric 中的 API 效率。
区域
跨区域调用通常是导致高延迟的原因。 为了获得最佳性能，建议让客户端连接到同一租户和容量区域中的 API。
租户区域
可以通过以下步骤找到租户区域：
- 使用管理员帐户转到 Microsoft Fabric 门户，然后单击右上角的“帮助
?”图标。 - 在 “帮助”部分底部，单击“关于 Fabric”链接。
- 将显示有关租户的详细信息，包括区域。
容量区域
转到 Microsoft Fabric 门户，打开托管 Fabric API for GraphQL 的工作区。
在 工作区设置中，转到 “许可证”信息。
可以在 “许可证容量”下找到容量区域信息。
数据源区域
如果数据源托管在 Fabric 平台中，工作区的容量区域将是数据源区域。
如果数据源位于 Fabric 平台外部（例如 Azure SQL 数据库）之外，则应能够在 Azure 门户中找到区域信息。
性能测试
对于评估其 API 性能的客户，我们建议遵循以下准则来确保一致且可靠的结果。
客户端工具
若要模拟应用程序的封闭环境行为，建议使用脚本或示例 Web 应用程序来进行测试来评估性能。 除此之外，使用 HTTP 连接池可以大大减少延迟，尤其是跨区域方案。
可以使用此示例 性能测试脚本 来帮助你入门。
相关文章：
数据收集和评估
建议使用脚本或性能测试工具在定义完善的时间段内自动执行请求。 分析基于平均值或百分位的结果有助于确保更准确和无偏见的性能度量。
常见问题
下面是可能影响 API 延迟和性能的常见问题的列表。
客户端地理位置与租户和容量区域不同：
- 如果打算为应用程序实现最佳性能，让同一区域中的客户端和 API 资源有助于实现目标。
在测试之前，请多次查询 GraphQL 的 API：
- 当 GraphQL 处于空闲状态时，其 API 不会使用或消耗容量单元（CUs）。 这意味着在第一次调用期间需要内部初始化 API 环境，这需要花费几秒钟的时间。 用于 GraphQL 的 API 具有内部缓存机制，可帮助减少连续调用的延迟，但初始调用可能会遇到延迟高峰。
- 除了 API 本身，某些数据源还已知会经历预热阶段，这将导致初始请求的延迟较高。 如果 API 正在访问同时处于空闲状态且恰好需要在首次执行期间初始化的数据源，则延迟更高，因为它需要等待数据源和 API 的初始化。
- 后续调用速度更快，因为环境初始化仅发生一次。
与数据源和 Fabric 容量相关的设置。
可以将适用于 GraphQL 的 API 视为数据源顶部的包装器。 如果数据源本身由于其复杂性的性质而出现性能问题，则预计 API 延迟可能很高。 发生此类情况时，建议直接测试查询数据源，以便与用于 GraphQL 的 API 进行更有效的性能比较。
- 请遵循本指南，了解如何选择合适的数据存储以满足您的业务需求：Fabric 决策指南 - 选择数据存储
访问 GraphQL API 时，性能将由所选的 Fabric 容量 SKU 绑定。
- 请参阅有关 Fabric 容量 SKU 及其计算能力的一般指南： Microsoft Fabric 概念
多种因素可能会影响 API 性能。 了解数据源设置、选择正确的区域并有效地衡量性能对于优化至关重要。