Skip to main content

此版本的 GitHub Enterprise 已停止服务 2022-09-28. 即使针对重大安全问题,也不会发布补丁。 为了获得更好的性能、更高的安全性和新功能,请升级到最新版本的 GitHub Enterprise。 如需升级帮助,请联系 GitHub Enterprise 支持

资源限制

GitHub GraphQL API 利用限制防止过度或胡乱调用 GitHub 的服务器。

节点限制

若要通过架构验证,所有 GraphQL API 调用都必须满足以下标准:

  • 客户端必须在任何连接上提供 firstlast 参数。
  • firstlast 的值必须在 1-100 以内。
  • 单个调用请求的节点总数不能超过 500,000。

计算调用中的节点

下面两个示例显示如何计算调用中的节点总数。

  1. 简单查询:

    query {
      viewer {
        repositories(first: 50) {
          edges {
            repository:node {
              name
    
              issues(first: 10) {
                totalCount
                edges {
                  node {
                    title
                    bodyHTML
                  }
                }
              }
            }
          }
        }
      }
    }

    计算:

    50         = 50 repositories
     +
    50 x 10  = 500 repository issues
    
                = 550 total nodes
  2. 复杂查询:

    query {
      viewer {
        repositories(first: 50) {
          edges {
            repository:node {
              name
    
              pullRequests(first: 20) {
                edges {
                  pullRequest:node {
                    title
    
                    comments(first: 10) {
                      edges {
                        comment:node {
                          bodyHTML
                        }
                      }
                    }
                  }
                }
              }
    
              issues(first: 20) {
                totalCount
                edges {
                  issue:node {
                    title
                    bodyHTML
    
                    comments(first: 10) {
                      edges {
                        comment:node {
                          bodyHTML
                        }
                      }
                    }
                  }
                }
              }
            }
          }
        }
    
        followers(first: 10) {
          edges {
            follower:node {
              login
            }
          }
        }
      }
    }

    计算:

    50              = 50 repositories
     +
    50 x 20       = 1,000 pullRequests
     +
    50 x 20 x 10 = 10,000 pullRequest comments
     +
    50 x 20       = 1,000 issues
     +
    50 x 20 x 10 = 10,000 issue comments
     +
    10              = 10 followers
    
                     = 22,060 total nodes

速率限制

GraphQL API 限制不同于 REST API 的速率限制

API 速率限制为什么不同? 使用 GraphQL,一个 GraphQL 调用可以替换 多个 REST 调用。 单个复杂 GraphQL 调用可能相当于数千个 REST 请求。 虽然单个 GraphQL 调用远远低于 REST API v3 速率限制,但对 GitHub 的服务器来说,查询的计算成本可能同样高昂。

为了准确表示查询的服务器成本,GraphQL API 将根据标准化点数来计算调用的速率限制分数。 查询分数计入了父连接及其子连接上的第一个和最后一个参数。

  • 公式使用父连接及其子连接上的 firstlast 参数预计算 GitHub 系统上的潜在负载,如 MySQL、ElasticSearch 和 Git。
  • 每个连接都有自己的点值。 此点值与调用的其他点数相结合,计入总速率限制分数。

GraphQL API 速率限制为每小时 5,000 点。

请注意,每小时 5,000 点与每小时 5,000 个调用不同:GraphQL API 和 REST API 使用的速率限制不同。

注意:在我们观察开发者如何使用 GraphQL API 时,当前公式和速率限制可能会发生更改。

返回调用的速率限制状态

使用 REST API,你可以通过检查返回的 HTTP 标头来检查速率限制状态。

使用 GraphQL API,你可以通过查询 rateLimit 对象上的字段来检查速率限制状态:

query {
  viewer {
    login
  }
  rateLimit {
    limit
    cost
    remaining
    resetAt
  }
}
  • limit 字段返回客户端在 60 分钟窗口期限内允许使用的最大客户端点数。

  • cost 字段返回计入速率限制的当前调用的点成本。

  • remaining 字段返回当前速率限制窗口中剩余的点数。)

  • resetAt 字段返回当前速率限制窗口重置的时间,单位为 UTC 纪元秒

在运行调用之前计算速率限制分数

查询 rateLimit 对象时会返回调用的分数,但运行调用时会计入限制。 为避免这种两难局面,可以在运行之前计算调用分数。 下面的计算结果与 rateLimit { cost } 返回的成本大致相同。

  1. 将完成调用中每个独有连接所需的请求数加起来。 假设每个请求都将达到 firstlast 参数限制。
  2. 将数字除以 100,然后将结果四舍五入,获取最终的聚合成本。 这一步可使大数字规范化。

注意:调用 GraphQL API 的最低成本为 1,表示单一请求。

下面是一个查询和分数计算示例:

query {
  viewer {
    login
    repositories(first: 100) {
      edges {
        node {
          id

          issues(first: 50) {
            edges {
              node {
                id

                labels(first: 60) {
                  edges {
                    node {
                      id
                      name
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

此查询需要 5,101 个请求才能完成:

  • 虽然我们要返回 100 个存储库,但 API 必须连接到查看器的帐户一次才能获取存储库列表。 因此,存储库的请求 = 1
  • 虽然我们要返回 50 个问题,但 API 必须与 100 个存储库的每个库相连接,才能获取问题列表。 因此,问题请求 = 100
  • 虽然我们要返回 60 个标签,但 API 必须与 5,000 个潜在总问题中的每个问题相连接,才能获取标签列表。 因此,标签请求 = 5,000
  • 总计 = 5,101

除以100,然后四舍五入就得到了查询的最终分数:51