Ressourcenbeschränkungen

Knotenlimit

Um die Schemaüberprüfung zu bestehen, müssen alle GraphQL-API-Aufrufe folgende Standards erfüllen:

Clients müssen ein Argument first oder last für eine beliebige Verbindung angeben.
Werte von first und last müssen innerhalb von 1-100 liegen.
Einzelne Aufrufe können nicht mehr als 500.000 Knoten insgesamt anfordern.

Berechnen von Knoten in einem Aufruf

In diesen beiden Beispielen wird gezeigt, wie die Knoten insgesamt in einem Aufruf berechnet werden.

Einfache Abfrage:

query {
  viewer {
    repositories(first: 50) {
      edges {
        repository:node {
          name

          issues(first: 10) {
            totalCount
            edges {
              node {
                title
                bodyHTML
              }
            }
          }
        }
      }
    }
  }
}

Berechnung:

50         = 50 repositories
 +
50 x 10  = 500 repository issues

            = 550 total nodes

Komplexe Abfrage:

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
        }
      }
    }
  }
}

Berechnung:

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

Rate Limit

Der GraphQL-API-Grenzwert unterscheidet sich von den REST-API-Ratenbegrenzungen.

Warum unterscheiden sich die API-Ratenbegrenzungen? Mit GraphQL kann ein GraphQL-Aufruf mehrere REST-Anrufe ersetzen. Ein einzelner komplexer GraphQL-Aufruf könnte das Äquivalent von Tausenden von REST-Anforderungen sein. Während ein einzelner GraphQL-Aufruf deutlich unter der REST-API-Ratenbegrenzung liegt, könnte die Abfrage für die GitHub-Server genauso teuer sein, um sie zu berechnen.

Um die Serverkosten einer Abfrage genau darzustellen, berechnet die GraphQL-API basierend auf einer normalisierten Punkteskala eine Bewertung der Ratenbegrenzung des Aufrufs. Die Bewertungsfaktoren einer Abfrage in den ersten und letzten Argumenten für eine übergeordnete Verbindung und deren untergeordnete Elemente.

Die Formel verwendet die Argumente first und last für eine übergeordnete Verbindung und ihre untergeordneten Elemente, um die potenzielle Last auf GitHub-Systemen, wie MySQL, ElasticSearch und Git, vorzurechnen.
Jede neue Verbindung verfügt über einen eigenen Punktwert. Punkte werden mit anderen Punkten aus dem Aufruf in eine Bewertung der Gesamtratenbegrenzung kombiniert.

Die GraphQL-API-Ratenbegrenzung beträgt 5.000 Punkte pro Stunde.

Beachte, dass 5.000 Punkte pro Stunde nicht gleich 5.000 Aufrufe pro Stunde sind: Die GraphQL-API und die REST-API verwenden verschiedene Ratenbegrenzungen.

Hinweis: Änderungen an den aktuellen Formel- und Ratenbegrenzungen sind vorbehalten, da noch untersucht wird, wie Entwickler*innen die GraphQL-API verwenden.

Zurückgeben des Ratenbegrenzungsstatus eines Anrufs

Mit der REST-API kannst du den Ratenbegrenzungsstatus überprüfen, indem du die zurückgegebenen HTTP-Header untersuchst.

Mit der GraphQL-API kannst du den Ratenbegrenzungsstatus überprüfen, indem du die Felder im Objekt rateLimit abfragst:

query {
  viewer {
    login
  }
  rateLimit {
    limit
    cost
    remaining
    resetAt
  }
}

Das Feld limit gibt die maximale Anzahl von Punkten zurück, die der Client in einem 60-Minuten-Fenster verwenden darf.
Das Feld cost gibt die Punktkosten für den aktuellen Aufruf zurück, der gegen die Ratenbegrenzung zählt.
Das Feld remaining gibt die Anzahl der Punkte zurück, die im aktuellen Ratenbegrenzungsfenster verbleiben.
Das Feld resetAt gibt die Uhrzeit im Format ISO 8601 zurück, zu der das aktuelle Ratenbegrenzungsfenster zurückgesetzt wird.

Berechnen einer Ratenbegrenzungsbewertung vor dem Ausführen des Aufrufs

Das Abfragen des Objekts rateLimit gibt die Bewertung eines Aufrufs zurück, aber das Ausführen des Aufrufs zählt gegen den Begrenzungswert. Um dieses Dilemma zu vermeiden, kannst du die Bewertung eines Aufrufs berechnen, bevor du ihn ausführst. Die folgende Berechnung funktioniert ungefähr mit den gleichen Kosten, die rateLimit { cost } zurückgibt.

Füge die Anzahl der Anforderungen hinzu, die erforderlich sind, um jede eindeutige Verbindung im Aufruf zu erfüllen. Angenommen, jede Anforderung erreicht die Grenzwerte der Argumente first oder last.
Teile die Zahl durch 100 und runde das Ergebnis ab, um die endgültigen Gesamtkosten zu erhalten. In diesem Schritt werden große Zahlen normalisiert.

Hinweis: Die Mindestkosten eines Aufrufs der GraphQL-API betragen 1, was eine einzelne Anforderung darstellt.

Hier ist eine Beispielabfrage und Bewertungsberechnung:

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

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

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

Für diese Abfrage sind 5.101 Anforderungen erforderlich:

Obwohl 100 Repositorys zurückgeben werden, muss die API einmal eine Verbindung mit dem Konto des Viewers herstellen, um die Liste der Repositorys abzurufen. Daher, Anforderungen für Repositorys = 1
Obwohl 50 Issues zurückgegeben werden, muss die API eine Verbindung mit jedem der 100 Repositorys herstellen, um die Liste der Issues abzurufen. Daher, Anforderungen für Issues = 100
Obwohl 60 Bezeichnungen zurückgegeben werden, muss die API eine Verbindung mit jedem der insgesamt möglichen 5.000 potenziellen Issues herstellen, um die Liste der Bezeichnungen abzurufen. Daher, Anforderungen für Bezeichnungen = 5.000
Gesamt = 5.101

Dividiert durch 100 und gerundet ergibt sich die endgültige Bewertung der Abfrage: 51