기본 트래픽률 제한
기본적으로 GitHub Enterprise Server에 대한 트래픽률 제한은 사용하지 않도록 설정됩니다. 인스턴스에 대한 트래픽률 제한을 확인하려면 사이트 관리자에게 문의하세요.
사이트 관리자는 인스턴스에 대한 트래픽률 제한을 설정할 수 있습니다. 자세한 내용은 속도 제한 구성을(를) 참조하세요.
인스턴스 외부의 사용자 또는 조직을 위한 앱을 개발하는 경우 표준 GitHub 트래픽률 제한이 적용됩니다. 자세한 내용은 GitHub Free 설명서의 GraphQL API에 대한 속도 제한 및 쿼리 제한을(를) 참조하세요.
노드 제한
스키마 유효성 검사를 통과하려면 모든 GraphQL API 호출이 다음 표준을 충족해야 합니다.
- 클라이언트는 모든 연결에서
first
또는last
인수를 제공해야 합니다. first
및last
의 값은 1~100 이내여야 합니다.- 개별 호출은 총 500,000개를 초과하는 노드를 요청할 수 없습니다.
호출에서 노드 계산
이 두 예제에서는 호출에서 총 노드를 계산하는 방법을 보여 줍니다.
-
단순 쿼리:
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
-
복합 쿼리:
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
쿼리 최적화 전략
- 개체 수 제한:
first
또는last
인수에 값을 더 작게 설정하고, 결과는 페이지네이션으로 조회 - 쿼리 깊이 줄이기: 필요한 경우가 아니면 깊게 중첩된 개체 요청 피하기
- 결과 필터링: 인수를 사용하여 데이터를 필터링하고 필요한 항목만 반환
- 대규모 쿼리 분할: 복잡한 쿼리를 여러 개의 더 단순한 쿼리로 분할
- 필요한 필드만 요청: 사용 가능한 모든 필드를 요청하는 대신 필요한 필드만 선택
이러한 전략을 따르면 리소스 제한에 도달할 가능성을 줄이고, API 요청의 성능과 안정성을 향상시킬 수 있습니다.