Microsoft Fabric 的 GraphQL API 提供了一种高效查询数据的强大方法，但性能优化是确保流畅且可缩放性能的关键。 无论是处理复杂的查询还是优化响应时间，以下最佳做法都有助于充分利用 GraphQL 实现的最佳性能，并最大程度地提高 Fabric 中的 API 效率。
谁需要性能优化
性能优化对于……至关重要。
- 应用程序开发人员 构建查询 Fabric 数据湖和数据仓库的高访问量应用程序
- 数据工程师优化Fabric数据访问模式，用于大规模分析应用程序和ETL过程
- Fabric 工作区管理员 管理容量消耗并确保的资源利用率高效
- BI 开发人员 改进了基于 Fabric 数据的自定义分析应用程序的响应时间
- DevOps 团队 排查生产应用程序中使用 Fabric API 的延迟问题
当 GraphQL API 需要高效处理生产工作负荷或遇到性能问题时，请使用这些最佳做法。
区域对齐
跨区域 API 调用是高延迟的常见原因。 为了获得最佳性能，请确保客户端应用程序、Fabric 租户、容量和数据源都位于同一 Azure 区域中。
检查租户区域
若要查找 Fabric 租户的区域，请执行以下操作：
- 使用管理员帐户登录到 Microsoft Fabric 门户
- 选择右上角的“帮助”图标（？）
- 在“帮助”窗格底部，选择关于 Fabric
- 记下租户详细信息中显示的区域
检查容量区域
GraphQL 的 API 在特定容量内运行。 若要找到容量区域，请执行以下步骤：
打开托管用于 GraphQL 的 API 的工作区
转到 工作区设置>许可证信息
在“许可证容量”下查找区域
检查数据源区域
数据源的位置也会影响性能：
- 构造数据源 （Lakehouse、数据仓库、SQL 数据库）：这些数据源使用与工作区容量相同的区域
- 外部数据源 （Azure SQL 数据库等）：在 Azure 门户中检查资源位置
最佳做法：将客户端应用程序部署到与 Fabric 容量和数据源相同的区域中，以最大程度地减少网络延迟。
性能测试最佳做法
评估 API 的性能时，请遵循以下准则，获取可靠且一致的结果。
使用逼真的测试工具
使用与生产环境密切相关的工具进行测试：
- 脚本或应用程序：使用 Python、Node.js或 .NET 脚本来模拟实际客户端行为
- HTTP 连接池：重复使用 HTTP 连接以减少延迟，对于跨区域方案尤其重要
- 会话管理：跨请求维护会话，以准确反映实际使用情况
示例资源：
- 示例性能测试脚本 （Python 笔记本）
- Python 中的 HTTP 会话对象
- .NET 的 HttpClient 指南
收集有意义的指标
若要进行准确的性能评估：
- 自动测试：使用脚本或性能测试工具在定义的时间段内一致地运行测试
- 预热 API：在测量性能之前执行多个测试查询（请参阅 预热要求）
- 分析分布：使用基于百分位的指标（P50、P95、P99），而不仅仅是平均值来了解延迟模式
- 负载下测试：使用实际并发请求卷测量性能
- 记录条件：在测试期间记录一天的时间、容量利用率和任何并发工作负荷
常见性能问题
了解这些常见问题有助于有效地诊断和解决性能问题。
预热要求
问题：第一个 API 请求比后续请求长得多。
原因：
- API 初始化：空闲时，API 环境需要在首次调用期间进行初始化，并添加几秒钟的延迟
- 数据源预热：许多数据源（尤其是 SQL Analytics 终结点和数据仓库）在空闲后访问后会经历预热阶段
- 合并初始化：如果 API 和数据源都处于空闲状态，则初始化时间复合
Solution:
- 在测量性能之前执行 2-3 个测试查询
- 对于生产应用程序，实现使 API 保持暖状态的运行状况检查终结点
- 请考虑使用计划查询或监控工具，以便在工作时间内保持系统活跃。
区域不对齐
问题：在所有请求中始终高延迟。
为什么发生这种情况： 跨区域网络调用会显著增加延迟，尤其是在客户端、API 和数据源位于不同的 Azure 区域中时。
Solution:
- 验证客户端应用程序、Fabric 容量和数据源是否位于同一区域
- 如果无法避免跨区域访问，请实施积极的缓存策略
- 考虑为全局应用程序部署区域 API 副本
数据源性能
问题：即使 API 已预热且区域保持一致，API 请求也会变慢。
为什么发生这种情况： GraphQL 的 API 作为数据源的查询接口。 如果基础数据源存在性能问题（例如缺少索引、复杂查询或资源约束），API 将继承这些限制。
Solution:
- 直接测试：直接查询数据源（使用 SQL 或其他本机工具）建立基线性能
-
优化数据源：
- 为经常查询的列添加适当的索引
- 考虑适合你的用例的数据存储： 构造决策指南 - 选择数据存储
- 查看查询执行计划以获取优化机会
- 合适的容量：确保 Fabric 容量 SKU 提供足够的计算资源。 有关选择适当容量的指导，请参阅 Microsoft Fabric 概念 。
查询设计
问题：某些查询性能良好，而另一些查询速度较慢。
原因：
- 过度提取：请求的字段数超过必要的增加处理时间
- 深度嵌套：具有多个嵌套关系的级别查询需要执行多个解析程序
- 缺少筛选器：没有适当筛选器的查询可能会返回过多的数据
Solution:
- 仅请求 GraphQL 查询中所需的字段
- 尽可能限制嵌套关系的深度
- 在查询中使用适当的筛选器和分页
- 在适当情况下，请考虑将复杂查询分解为多个更简单的查询