{"meta":{"title":"Ограничения скорости и ограничения запросов для API GraphQL","intro":"GitHub API GraphQL имеет ограничения для защиты от чрезмерных или злоупотребленных вызовов GitHubсерверов .","product":"API GraphQL","breadcrumbs":[{"href":"/ru/enterprise-cloud@latest/graphql","title":"API GraphQL"},{"href":"/ru/enterprise-cloud@latest/graphql/overview","title":"Обзор"},{"href":"/ru/enterprise-cloud@latest/graphql/overview/rate-limits-and-query-limits-for-the-graphql-api","title":"Ограничения скорости и запросов"}],"documentType":"article"},"body":"# Ограничения скорости и ограничения запросов для API GraphQL\n\nGitHub API GraphQL имеет ограничения для защиты от чрезмерных или злоупотребленных вызовов GitHubсерверов .\n\n## Ограничение основной скорости\n\nAPI GraphQL назначает точки каждому запросу и ограничивает точки, которые можно использовать в течение определенного периода времени. Это ограничение помогает предотвратить злоупотребления и атаки типа \"отказ в обслуживании\" и гарантирует, что API остается доступным для всех пользователей.\n\nREST API также имеет отдельный основной предел скорости. Дополнительные сведения см. в разделе [Ограничения скорости для REST API](/ru/enterprise-cloud@latest/rest/using-the-rest-api/rate-limits-for-the-rest-api).\n\nКак правило, вы можете вычислить основной предел скорости для API GraphQL на основе метода проверки подлинности:\n\n* *Для пользователей*: 5000 точек в час на пользователя. Это включает запросы, сделанные как с помощью пользователя, personal access tokenGitHub AppOAuth app так и от имени пользователя, авторизовавшего приложение. Запросы, сделанные от имени пользователя, GitHub App принадлежащим организации GitHub Enterprise Cloud , имеют более высокий лимит ставки — 10 000 баллов в час. Аналогично, запросы, OAuth app сделанные от вашего имени компаниейGitHub Enterprise Cloud, принадлежащей или одобренной GitHub Enterprise Cloud организацией, имеют более высокий лимит ставки — 10 000 баллов в час, если вы являетесь членом организации.\n* *Для GitHub App установок, не входящих в GitHub Enterprise Cloud организацию или предприятие*: 5 000 очков в час за одну установку. Установки, имеющие более 20 репозиториев, получают еще 50 точек в час для каждого репозитория. Установки, которые находятся в организации с более чем 20 пользователями, получают еще 50 очков в час для каждого пользователя. Ограничение скорости не может превышать 12500 точек в час. Лимит скорости для токенов user access (в отличие от токенов установки access) определяется основным лимитом для пользователей.\n* *Для GitHub App установок в GitHub Enterprise Cloud организации или предприятии*: 10 000 очков в час за одну установку. Лимит скорости для токенов user access (в отличие от токенов установки access) определяется основным лимитом для пользователей.\n* *Для OAuth apps*: 5 000 баллов в час или 10 000 очков в час, если приложение принадлежит организации GitHub Enterprise Cloud . Это применяется только при использовании идентификатора клиента и секрета клиента для запроса общедоступных данных. Лимит скорости для токенов доступа OAuth, генерируемых a, OAuth app определяется основным лимитом для пользователей.\n* *Для `GITHUB_TOKEN` рабочих GitHub Actions процессов*: 1000 очков в час на репозиторий. Для запросов к ресурсам, принадлежащим корпоративному аккаунту на GitHub.com, лимит составляет 15 000 очков в час на репозиторий.\n\nМожно проверить значение точки запроса или вычислить ожидаемое значение точки, как описано в следующих разделах. Формула для вычисления точек и ограничения скорости подлежат изменению.\n\n### Проверка состояния основного ограничения скорости\n\nВы можете использовать заголовки, отправляемые с каждым ответом, чтобы определить текущее состояние основного ограничения скорости.\n\n| Имя заголовка           | Description                                                                                                     |\n| ----------------------- | --------------------------------------------------------------------------------------------------------------- |\n| `x-ratelimit-limit`     | Максимальное количество точек, которые можно использовать в час                                                 |\n| `x-ratelimit-remaining` | Количество точек, оставшихся в текущем окне ограничения скорости                                                |\n| `x-ratelimit-used`      | Количество точек, использованных в текущем окне ограничения скорости                                            |\n| `x-ratelimit-reset`     | Время сброса текущего ограничения скорости в секундах в формате UTC                                             |\n| `x-ratelimit-resource`  | Ресурс ограничения скорости, к которому подсчитывается запрос. Для запросов GraphQL это всегда будет `graphql`. |\n\nВы также можете запросить `rateLimit` объект, чтобы проверить ограничение скорости. По возможности следует использовать заголовки ответов ограничения скорости вместо запроса API, чтобы проверить ограничение скорости.\n\n```graphql\nquery {\n  viewer {\n    login\n  }\n  rateLimit {\n    limit\n    remaining\n    used\n    resetAt\n  }\n}\n```\n\n| Поле        | Description                                                          |\n| ----------- | -------------------------------------------------------------------- |\n| `limit`     | Максимальное количество точек, которые можно использовать в час      |\n| `remaining` | Количество точек, оставшихся в текущем окне ограничения скорости     |\n| `used`      | Количество точек, использованных в текущем окне ограничения скорости |\n| `resetAt`   | Время сброса текущего ограничения скорости в секундах в формате UTC  |\n\n### Возврат значения точки запроса\n\nВы можете вернуть значение точки запроса, запросив `cost` поле в объекте `rateLimit` :\n\n```graphql\nquery {\n  viewer {\n    login\n  }\n  rateLimit {\n    cost\n  }\n}\n```\n\n### Прогнозирование значения точки запроса\n\nВы также можете примерно вычислить значение точки запроса перед выполнением запроса.\n\n1. Сложите количество запросов, необходимых для выполнения каждого уникального подключения в вызове. Предположим, что каждый запрос будет достигать ограничений для аргумента `first` или `last`.\n2. Разделите число на **100** и округите результат до ближайшего целого числа, чтобы получить окончательное значение статистической точки. На этом шаге нормализуется большое число.\n\n> \\[!NOTE]\n> Минимальное значение точки вызова API GraphQL равно **1**.\n\nНиже приведен пример запроса и вычисления оценки.\n\n```graphql\nquery {\n  viewer {\n    login\n    repositories(first: 100) {\n      edges {\n        node {\n          id\n\n          issues(first: 50) {\n            edges {\n              node {\n                id\n\n                labels(first: 60) {\n                  edges {\n                    node {\n                      id\n                      name\n                    }\n                  }\n                }\n              }\n            }\n          }\n        }\n      }\n    }\n  }\n}\n```\n\nДля выполнения этого запроса требуется 5101 вызов:\n\n* Хотя возвращается 100 репозиториев, API должен подключиться к учетной записи зрителя **один раз**, чтобы получить список репозиториев. Таким образом, число запросов для репозиториев = **1**.\n* Хотя возвращается 50 проблем, API должен подключиться к каждому из **100** репозиториев, чтобы получить список проблем. Таким образом, число запросов для проблем = **100**.\n* Хотя возвращается 60 меток, API должен подключиться к каждой из **5000** потенциальных проблем, чтобы получить список меток. Таким образом, число запросов для меток = **5000**.\n* Всего **5101** запрос.\n\nРазделим на 100, округлим, и получим окончательную оценку для запроса: **51**.\n\n## Дополнительные ограничения скорости\n\nПомимо ограничений основной частоты GitHub применяет ограничения вторичной частоты, чтобы предотвратить злоупотребление и сохранить API доступным для всех пользователей.\n\nЕсли вы можете столкнуться с дополнительным ограничением скорости:\n\n* *Сделайте слишком много одновременных запросов.* Допускается не более 100 одновременных запросов. Это ограничение используется для REST API и API GraphQL.\n* *Сделайте слишком много запросов к одной конечной точке в минуту.* Для конечных точек REST API разрешено не более 900 точек в минуту, а для конечной точки API GraphQL разрешено не более 2000 точек в минуту. Дополнительные сведения о точках см. в разделе [\"Вычисление точек\" для дополнительного ограничения скорости](#calculating-points-for-the-secondary-rate-limit).\n* *Сделайте слишком много запросов в минуту.* Допускается не более 90 секунд ЦП в 60 секунд в реальном времени. Не более 60 секунд этого времени ЦП может быть для API GraphQL. Вы можете приблизительно оценить время ЦП, измеряя общее время отклика для запросов API.\n* *Слишком много запросов, которые потребляют чрезмерные вычислительные ресурсы в течение короткого периода времени.*\n* *Создание слишком большого объема содержимого на GitHub в течение короткого времени.* Как правило, не более 80 запросов на создание содержимого в минуту и не более 500 запросов на создание контента в час. Некоторые конечные точки имеют более низкие ограничения на создание контента. Ограничения создания контента включают действия, выполняемые на веб-интерфейсе GitHub и через REST API и API GraphQL.\n* *Сделайте слишком много запросов на токены доступа OAuth за короткое время.* Не более 2 000 запросов на OAuth token доступа в час для GitHub Apps и OAuth apps.\n\nЭти ограничения вторичной ставки подлежат изменению без уведомления. Вы также можете столкнуться с дополнительным ограничением скорости по нераскрытым причинам.\n\n### Вычисление точек для дополнительного ограничения скорости\n\nНекоторые ограничения вторичной частоты определяются значениями точек запросов. Для запросов GraphQL эти значения точек отделены от вычислений значений точек для основного ограничения скорости.\n\n| Запросить                                                     | Точки |\n| ------------------------------------------------------------- | ----- |\n| Запросы GraphQL без изменений                                 | 1     |\n| Запросы GraphQL с изменениями                                 | 5     |\n| Большинство REST API `GET`и `HEAD``OPTIONS` запросов          | 1     |\n| Большинство REST API`POST`, `PATCH``PUT`или `DELETE` запросов | 5     |\n\nНекоторые конечные точки REST API имеют другую стоимость точки, которая не является общедоступной.\n\n## Превышение предела скорости\n\nЕсли вы превышаете основной предел частоты, состояние ответа по-прежнему будет отображаться`200`, но вы получите сообщение об ошибке, а значение заголовка `x-ratelimit-remaining` будет.`0` Не следует повторять запрос до тех пор, пока не указано время, указанное заголовком `x-ratelimit-reset` .\n\nЕсли превышено ограничение вторичной скорости, состояние ответа будет `200` или `403`, и вы получите сообщение об ошибке, указывающее, что вы достигли дополнительного ограничения скорости.\n`retry-after` Если заголовок ответа присутствует, не следует повторять запрос до тех пор, пока не истекло много секунд. Если заголовок `x-ratelimit-remaining` имеет значение `0`, то не следует повторять запрос до тех пор, пока не будет время, в секундах эпохи UTC, указанных заголовком `x-ratelimit-reset` . В противном случае дождитесь хотя бы одной минуты, прежде чем повторить попытку. Если запрос продолжает завершаться ошибкой из-за дополнительного ограничения скорости, подождите экспоненциально увеличивающееся время между повторными попытками и вызовите ошибку после определенного числа повторных попыток.\n\nПродолжая делать запросы во время ограничения скорости, может привести к запрету интеграции.\n\n## Оставаться под ограничением скорости\n\nЧтобы избежать превышения ограничения скорости, следует приостановить по крайней мере 1 секунду между мутативными запросами и избежать одновременных запросов.\n\nКроме того, следует подписаться на события веб-перехватчика вместо опроса API для данных. Дополнительные сведения см. в разделе [Документация по веб-перехватчикам](/ru/enterprise-cloud@latest/webhooks).\n\nВы также можете потоковую передачу журнала аудита для просмотра запросов API. Это поможет устранить неполадки интеграции, превышающие ограничение скорости. Дополнительные сведения см. в разделе [Потоковая передача журнала аудита для предприятия](/ru/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise).\n\n## Предельное число узлов\n\nДля прохождения валидации [schema](/ru/enterprise-cloud@latest/graphql/guides/introduction-to-graphql#schema) все API GraphQL [calls](/ru/enterprise-cloud@latest/graphql/guides/forming-calls-with-graphql) должны соответствовать следующим стандартам:\n\n* Клиенты должны предоставить аргумент `first` или `last` по любому [связи](/ru/enterprise-cloud@latest/graphql/guides/introduction-to-graphql#connection).\n* Значения `first` и `last` должны находиться в пределах 1–100.\n* Отдельные звонки не могут запрашивать более 500 000 [узлов](/ru/enterprise-cloud@latest/graphql/guides/introduction-to-graphql#node).\n\n### Подсчет узлов в вызове\n\nВ этих двух примерах показано, как вычислить общее количество узлов в вызове.\n\n1. Простой запрос:\n\n   <pre>query {\n     viewer {\n       repositories(first: <span class=\"redbox\">50</span>) {\n\nedges {\nrepository:node {\nname\n\nissues(first: <span class=\"greenbox\">10</span>) {\ntotalCount\nedges {\nnode {\ntitle\nbodyHTML\n}\n}\n}\n}\n}\n}\n}\n}</pre>\n\nРасчет:\n\n   <pre><span class=\"redbox\">50</span>         = 50 repositories\n    +\n   <span class=\"redbox\">50</span> x <span class=\"greenbox\">10</span>  = 500 repository issues\n\n= 550 total nodes</pre>\n\n1. Сложный запрос:\n\n   <pre>query {\n     viewer {\n       repositories(first: <span class=\"redbox\">50</span>) {\n\nedges {\nrepository:node {\nname\n\npullRequests(first: <span class=\"greenbox\">20</span>) {\nedges {\npullRequest:node {\ntitle\n\ncomments(first: <span class=\"bluebox\">10</span>) {\nedges {\ncomment:node {\nbodyHTML\n}\n}\n}\n}\n}\n}\n\nissues(first: <span class=\"greenbox\">20</span>) {\ntotalCount\nedges {\nissue:node {\ntitle\nbodyHTML\n\ncomments(first: <span class=\"bluebox\">10</span>) {\nedges {\ncomment:node {\nbodyHTML\n}\n}\n}\n}\n}\n}\n}\n}\n}\n\n```\n   followers(first: <span class=\"bluebox\">10</span>) {\n```\n\nedges {\nfollower:node {\nlogin\n}\n}\n}\n}\n}</code></pre>\n\nРасчет:\n\n   <pre><span class=\"redbox\">50</span>              = 50 repositories\n    +\n   <span class=\"redbox\">50</span> x <span class=\"greenbox\">20</span>       = 1,000 pullRequests\n    +\n   <span class=\"redbox\">50</span> x <span class=\"greenbox\">20</span> x <span class=\"bluebox\">10</span> = 10,000 pullRequest comments\n    +\n   <span class=\"redbox\">50</span> x <span class=\"greenbox\">20</span>       = 1,000 issues\n    +\n   <span class=\"redbox\">50</span> x <span class=\"greenbox\">20</span> x <span class=\"bluebox\">10</span> = 10,000 issue comments\n    +\n   <span class=\"bluebox\">10</span>              = 10 followers\n\n= 22,060 total nodes</pre>\n\n## Время ожидания\n\nЕсли GitHub обработка запроса API-запроса занимает более 10 секунд, GitHub запрос будет завершен, и вы получите ответ на тайм-аут и сообщение о том, что «Мы не смогли ответить на ваш запрос вовремя».\n\nКогда это происходит, вы можете получить либо статус кода a `502` или `504` . Оба статуса указывают на то, что ваш запрос истёк.\n\nGitHub оставляет за собой право изменять окно тайм-аута для защиты скорости и надёжности API.\n\nВы можете проверить состояние API GraphQL на [githubstatus.com](https://www.githubstatus.com/) , чтобы определить, связано ли время ожидания с API. Вы также можете попытаться упростить запрос или попробовать его позже. Для советов по улучшению эффективности запросов смотрите [стратегии оптимизации запросов](#query-optimization-strategies).\n\nЕсли время ожидания возникает для любого из запросов API, дополнительные баллы будут вычитаться из основного ограничения скорости в течение следующего часа, чтобы защитить скорость и надежность API.\n\n## Другие ограничения ресурсов\n\nДля защиты скорости и надёжности API GitHub также применяется другие ограничения по ресурсам. Если ваш запрос в GraphQL потребляет слишком много ресурсов, GitHub запрос прекратится и вернёт частичные результаты вместе с ошибкой, указывающей на превышение лимитов ресурсов.\n\n**Примеры запросов, которые могут превышать ограничения ресурсов:**\n\n* Запрос тысяч объектов или глубоко вложенных связей в одном запросе.\n* Одновременное использование больших `first` или `last` аргументов в нескольких подключениях.\n* Получение подробных сведений для каждого объекта, например всех комментариев, реакций и связанных проблем для каждого репозитория.\n\n## Стратегии оптимизации запросов\n\n* **Ограничение количества объектов**: используйте меньшие значения для `first` или `last` аргументов и размыкайтесь по результатам.\n* **Уменьшите глубину** запроса: не запрашивайте глубоко вложенные объекты, если это не необходимо.\n* **Результаты** фильтрации: используйте аргументы для фильтрации данных и возврата только необходимых данных.\n* **Разделение больших запросов**: разбиение сложных запросов на несколько простых запросов.\n* **Запрос только обязательных полей: выберите только нужные поля**, а не запрос всех доступных полей.\n\nСледуя этим стратегиям, вы можете снизить вероятность попадания ограничений ресурсов и повысить производительность и надежность запросов API."}