{"meta":{"title":"Ratenbegrenzungen und Abfragegrenzwerte für die GraphQL-API","intro":"Die GitHub GraphQL-API hat Einschränkungen, um vor übermäßigen oder missbräuchlichen Aufrufen von GitHubServern zu schützen.","product":"GraphQL-API","breadcrumbs":[{"href":"/de/enterprise-cloud@latest/graphql","title":"GraphQL-API"},{"href":"/de/enterprise-cloud@latest/graphql/overview","title":"Übersicht"},{"href":"/de/enterprise-cloud@latest/graphql/overview/rate-limits-and-query-limits-for-the-graphql-api","title":"Ratenbegrenzungen und Abfragegrenzwerte"}],"documentType":"article"},"body":"# Ratenbegrenzungen und Abfragegrenzwerte für die GraphQL-API\n\nDie GitHub GraphQL-API hat Einschränkungen, um vor übermäßigen oder missbräuchlichen Aufrufen von GitHubServern zu schützen.\n\n## Primäre Ratenbegrenzung\n\nDie GraphQL-API weist jeder Abfrage Punkte zu und begrenzt die Punkte, die Sie innerhalb eines bestimmten Zeitraums verwenden können. Dieses Limit trägt dazu bei, Missbrauch und Denial-of-Service-Angriffe zu verhindern, und stellt sicher, dass die API für alle Benutzer\\*innen verfügbar bleibt.\n\nDie REST-API verfügt auch über eine separate primäre Ratenbegrenzung. Weitere Informationen finden Sie unter [Ratenbegrenzungen für die REST-API](/de/enterprise-cloud@latest/rest/using-the-rest-api/rate-limits-for-the-rest-api).\n\nIm Allgemeinen können Sie Ihre primäre Ratenbegrenzung für die GraphQL-API basierend auf Ihrer Authentifizierungsmethode berechnen.\n\n* *Für Benutzer*: 5.000 Punkte pro Stunde und Benutzer. Dazu gehören sowohl Anfragen, die mit einem personal access token gestellt werden, als auch Anfragen, die von einem GitHub App oder OAuth app im Auftrag eines Benutzers gestellt werden, der die App autorisiert hat. Anfragen, die im Namen eines Benutzers von einem GitHub App gestellt werden, das einer GitHub Enterprise Cloud-Organisation gehört, haben eine höhere Ratenbegrenzung von 10.000 Punkten pro Stunde. Ebenso unterliegen Anfragen, die in Ihrem Namen von einem OAuth app, das sich im Besitz einer GitHub Enterprise Cloud Organisation befindet oder von einer solchen genehmigt wurde, gestellt werden, einem höheren Ratenlimit von 10.000 Punkten pro Stunde, wenn Sie Mitglied der Organisation GitHub Enterprise Cloud sind.\n* *Für GitHub App Installationen, die sich nicht in einer OrganisationGitHub Enterprise Cloud oder einem Unternehmen* befinden: 5.000 Punkte pro Stunde pro Installation. Installationen mit mehr als 20 Repositorys erhalten weitere 50 Punkte pro Stunde für jedes Repository. Installationen in einer Organisation mit mehr als 20 Benutzern erhalten weitere 50 Punkte pro Stunde für jeden Benutzer. Die Ratenbegrenzung darf nicht mehr als 12.500 Punkte pro Stunde betragen. Das Rate-Limit für Benutzerzugriffstoken (im Gegensatz zu Installationszugriffstoken) wird durch das primäre Rate-Limit für Benutzer bestimmt.\n* *Für GitHub App Installationen in einer Organisation oder einem GitHub Enterprise Cloud Unternehmen*: 10.000 Punkte pro Stunde pro Installation. Das Rate-Limit für Benutzerzugriffstoken (im Gegensatz zu Installationszugriffstoken) wird durch das primäre Rate-Limit für Benutzer bestimmt.\n* *Für OAuth apps*: 5.000 Punkte pro Stunde oder 10.000 Punkte pro Stunde, wenn die App im Besitz einer GitHub Enterprise Cloud Organisation ist. Dies gilt nur, wenn die App ihre Client-ID und den geheimen Clientschlüssel verwendet, um öffentliche Daten anzufordern. Das Ratenlimit für OAuth-Zugriffstoken, die von einem OAuth app generiert werden, wird durch das primäre Ratenlimit für Nutzer bestimmt.\n* *Für `GITHUB_TOKEN` in GitHub Actions-Workflows*: 1.000 Punkte pro Stunde pro Repository. Für Anforderungen an Ressourcen, die einem Unternehmenskonto bei GitHub.com angehören, beträgt der Grenzwert 15.000 Punkte pro Stunde pro Repository.\n\nSie können den Punktwert einer Abfrage überprüfen oder den erwarteten Punktwert berechnen, wie in den folgenden Abschnitten beschrieben. Die Formel für die Berechnung von Punkten und die Ratenbegrenzung können geändert werden.\n\n### Überprüfen des Status Ihrer primären Ratenbegrenzung\n\nSie können die Kopfzeilen verwenden, die mit jeder Antwort gesendet werden, um den aktuellen Status Ihrer primären Ratenbegrenzung zu ermitteln.\n\n| Headername | Beschreibung |\n| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------- |\n| `x-ratelimit-limit` | Die maximale Anzahl von Punkten, die Sie pro Stunde nutzen dürfen. |\n| `x-ratelimit-remaining` | Die Anzahl der Punkte, die im aktuellen Ratenbegrenzungsfenster verbleiben. |\n| `x-ratelimit-used` | Die Anzahl der Punkte, die Sie im aktuellen Ratenbegrenzungsfenster verwendet haben. |\n| `x-ratelimit-reset` | Der Zeitpunkt, zu dem das aktuelle Ratenbegrenzungsfenster zurückgesetzt wird, angegeben in UTC-Epochensekunden. |\n| `x-ratelimit-resource` | Die Ratenbegrenzungsressource, auf die die Anforderung angerechnet wird. Bei GraphQL-Anforderungen ist dies immer `graphql`. |\n\nSie können auch das `rateLimit`-Objekt abfragen, um Ihre Ratenbegrenzung zu überprüfen. Wenn möglich, sollten Sie die Antwortheader für die Ratenbegrenzung verwenden, anstatt die API abzurufen, um Ihre Ratenbegrenzung zu überprüfen.\n\n```graphql\nquery {\n viewer {\n login\n }\n rateLimit {\n limit\n remaining\n used\n resetAt\n }\n}\n```\n\n| Feld | Beschreibung |\n| ----------- | ---------------------------------------------------------------------------------------------------------------- |\n| `limit` | Die maximale Anzahl von Punkten, die Sie pro Stunde nutzen dürfen. |\n| `remaining` | Die Anzahl der Punkte, die im aktuellen Ratenbegrenzungsfenster verbleiben. |\n| `used` | Die Anzahl der Punkte, die Sie im aktuellen Ratenbegrenzungsfenster verwendet haben. |\n| `resetAt` | Der Zeitpunkt, zu dem das aktuelle Ratenbegrenzungsfenster zurückgesetzt wird, angegeben in UTC-Epochensekunden. |\n\n### Zurückgeben des Punktwerts einer Abfrage\n\nSie können den Punktwert einer Abfrage zurückgeben, indem Sie das Feld `cost` auf dem `rateLimit`-Objekt abfragen:\n\n```graphql\nquery {\n viewer {\n login\n }\n rateLimit {\n cost\n }\n}\n```\n\n### Vorhersagen des Punktwerts einer Abfrage\n\nSie können auch den Punktwert einer Abfrage grob berechnen, bevor Sie die Abfrage erstellen.\n\n1. Addiere die Anzahl der Anfragen, die erforderlich sind, um jede einzelne Verbindung im Anruf zu erfüllen. Angenommen, jede Anforderung erreicht die Grenzwerte der Argumente `first` oder `last`.\n2. Teilen Sie die Zahl durch **100** und runden Sie das Ergebnis auf die nächste ganze Zahl, um den endgültigen Punktwert zu erhalten. In diesem Schritt werden große Zahlen normalisiert.\n\n> \\[!NOTE]\n> Der Mindestpunktwert eines Aufrufs der GraphQL-API lautet **1**.\n\nHier ist eine Beispielabfrage und Bewertungsberechnung:\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\nFür diesen Abfragevorgang sind 5.101 Anfragen notwendig.\n\n* 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**\n* 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**\n* Obwohl wir 60 Labels zurückgeben, muss die API eine Verbindung zu jedem der insgesamt **5.000** potenziellen Probleme herstellen, um die Liste der Labels abzurufen. Daher Anfragen für Etiketten = **5.000**\n* Gesamt = **5.101**\n\nDividiert durch 100 und gerundet ergibt sich die endgültige Bewertung der Abfrage: **51**\n\n## Sekundäre Ratenbegrenzungen\n\nZusätzlich zu den Primärratenbegrenzungen erzwingt GitHub sekundäre Ratenbeschränkungen, um Missbrauch zu verhindern und die API für alle Benutzer verfügbar zu halten.\n\nWenn Sie folgende Aktionen ausführen, könnten Sie auf eine sekundäre Ratenbeschränkung stoßen:\n\n* *Zu hohe Anzahl gleichzeitiger Anforderungen.* Es sind nicht mehr als 100 gleichzeitige Anforderungen zulässig. Dieser Grenzwert wird für die REST-API und die GraphQL-API freigegeben.\n* *Nehmen Sie zu viele Anforderungen an einen einzelnen Endpunkt pro Minute vor.* Für REST-API-Endpunkte sind maximal 900 Punkte pro Minute zulässig und für den GraphQL-API-Endpunkt sind maximal 2 000 Punkte pro Minute zulässig. Weitere Informationen zu Punkten findest du unter [Berechnen von Punkten für das sekundäre Ratenbegrenzungen](#calculating-points-for-the-secondary-rate-limit).\n* *Stellen Sie zu viele Anfragen pro Minute.* Maximal 90 Sekunden CPU-Zeit pro 60 Sekunden Echtzeit ist zulässig. Es kann nicht mehr als 60 Sekunden dieser CPU-Zeit für die GraphQL-API sein. Sie können die CPU-Zeit grob schätzen, indem Sie die Gesamtantwortzeit für Ihre API-Anforderungen messen.\n* *Nehmen Sie zu viele Anforderungen vor, die in kurzer Zeit zu viele Computeressourcen verbrauchen.*\n* *Erstellen Sie in kurzer Zeit zu viele Inhalte für GitHub.* Im Allgemeinen sind nicht mehr als 80 Anforderungen zum Generieren von Inhalten pro Minute und maximal 500 Anforderungen zur Inhaltsgenerierung pro Stunde zulässig. Einige Endpunkte weisen niedrigere Grenzwerte für die Inhaltserstellung auf. Zu den Grenzwerten für die Inhaltserstellung gehören Aktionen, die auf der GitHub-Webschnittstelle sowie über die REST-API und die GraphQL-API ausgeführt werden.\n* *Nehmen Sie in kurzer Zeit zu viele OAuth-Zugriffstokenanforderungen vor.* Für GitHub Apps und OAuth apps sind maximal 2.000 OAuth-Zugriffstokenanforderungen pro Stunde zulässig.\n\nDiese Sekundärratenbegrenzungen können ohne Vorherige Ankündigung geändert werden. Es kann auch sein, dass Sie aus unbekannten Gründen auf eine sekundäre Ratenbegrenzung stoßen.\n\n### Berechnen von Punkten für die sekundäre Ratenbegrenzung\n\nEinige sekundäre Ratenbegrenzungen werden durch die Punktwerte der Anforderungen bestimmt. Bei GraphQL-Anforderungen sind diese Punktwerte getrennt von den Punktwertberechnungen für die primäre Ratenbegrenzung.\n\n| Anfrage | Punkte |\n| ----------------------------------------------------------------------------------- | ------ |\n| GraphQL-Anforderungen ohne Mutationen | 1 |\n| GraphQL-Anforderungen mit Mutationen | 5 |\n| Die meisten REST-API `GET`-, `HEAD`- und `OPTIONS`-Anforderungen | 1 |\n| Die meisten `POST`-, `PATCH`-, `PUT`- oder `DELETE`-Anforderungen über die REST-API | 5 |\n\nEinige REST-API-Endpunkte haben einen anderen Kostenpunkt, der nicht öffentlich freigegeben wird.\n\n## Überschreiten der Ratenbegrenzung\n\nWenn Sie die primäre Ratenbegrenzung überschreiten, lautet der Antwortstatus weiterhin `200`, aber Sie erhalten eine Fehlermeldung, und der Wert der `x-ratelimit-remaining`-Kopfzeile lautet `0`. Sie sollten die Anforderung erst nach Ablauf der im `x-ratelimit-reset`-Header angegebenen Zeit wiederholen.\n\nWenn Sie eine sekundäre Ratenbegrenzung überschreiten, lautet der Antwortstatus `200` oder `403`, und Sie erhalten eine Fehlermeldung, die angibt, dass Sie die sekundäre Ratenbegrenzung überschritten haben. Wenn der Antwortheader `retry-after` vorhanden ist, sollten Sie Ihre Anforderung erst nach Ablauf dieser Sekundenzahl erneut übermitteln. Wenn der `x-ratelimit-remaining`-Header `0` lautet, solltest du die Anforderung erst nach Ablauf der im `x-ratelimit-reset`-Header angegebenen UTC-Epochensekunden erneut senden. Warte andernfalls mindestens eine Minute, bevor du den Vorgang wiederholst. Wenn Ihre Anforderung aufgrund einer sekundären Ratenbegrenzung weiterhin fehlschlägt, warten Sie auf eine exponentiell steigende Zeitspanne zwischen Wiederholungen, und lösen Sie nach einer bestimmten Anzahl von Wiederholungen einen Fehler aus.\n\nWenn Sie weiterhin Anfragen stellen, während Sie von einer Ratenbegrenzung betroffen sind, kann dies zu einer Sperrung Ihrer Integration führen.\n\n## Unterhalb der Ratenbegrenzung bleiben\n\nUm die Überschreitung einer Ratenbegrenzung zu vermeiden, sollten Sie mindestens 1 Sekunde zwischen mutativen Anforderungen pausieren und gleichzeitige Anforderungen vermeiden.\n\nAbonnieren Sie auch Webhook-Ereignisse, anstatt Daten von der API abzurufen. Weitere Informationen finden Sie unter [Webhooks-Dokumentation](/de/enterprise-cloud@latest/webhooks).\n\nSie können das Überwachungsprotokoll auch streamen, um API-Anforderungen anzuzeigen. Dies kann Ihnen bei der Problembehandlung bei Integrationen helfen, die die Ratenbegrenzung überschreiten. Weitere Informationen finden Sie unter [Streaming des Überwachungsprotokolls für Ihre Organisation](/de/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise).\n\n## Knotenlimit\n\nDamit die Schemaüberprüfung bestanden wird, müssen alle GraphQL-API-Aufrufe diese Standards erfüllen:\n\n* Kunden müssen ein `first`- oder `last`-Argument bei jeder [Verbindung](/de/enterprise-cloud@latest/graphql/guides/introduction-to-graphql#connection) angeben.\n* Werte von `first` und `last` müssen innerhalb von 1-100 liegen.\n* Einzelne Aufrufe können nicht mehr als 500.000 [Knoten](/de/enterprise-cloud@latest/graphql/guides/introduction-to-graphql#node) insgesamt anfordern.\n\n### Berechnen von Knoten in einem Aufruf\n\nIn diesen beiden Beispielen wird gezeigt, wie die Knoten insgesamt in einem Aufruf berechnet werden.\n\n1. Einfache Abfrage:\n\n query {\n viewer {\n repositories(first: 50) {\n\nedges {\nrepository:node {\nname\n\nissues(first: 10) {\ntotalCount\nedges {\nnode {\ntitle\nbodyHTML\n}\n}\n}\n}\n}\n}\n}\n}\n\nBerechnung:\n\n 50 = 50 repositories\n +\n 50 x 10 = 500 repository issues\n\n= 550 total nodes
\n\n1. Komplexe Abfrage:\n\n query {\n viewer {\n repositories(first: 50) {\n\nedges {\nrepository:node {\nname\n\npullRequests(first: 20) {\nedges {\npullRequest:node {\ntitle\n\ncomments(first: 10) {\nedges {\ncomment:node {\nbodyHTML\n}\n}\n}\n}\n}\n}\n\nissues(first: 20) {\ntotalCount\nedges {\nissue:node {\ntitle\nbodyHTML\n\ncomments(first: 10) {\nedges {\ncomment:node {\nbodyHTML\n}\n}\n}\n}\n}\n}\n}\n}\n}\n\n```\n followers(first: 10) {\n```\n\nedges {\nfollower:node {\nlogin\n}\n}\n}\n}\n}\n\nBerechnung:\n\n 50 = 50 repositories\n +\n 50 x 20 = 1,000 pullRequests\n +\n 50 x 20 x 10 = 10,000 pullRequest comments\n +\n 50 x 20 = 1,000 issues\n +\n 50 x 20 x 10 = 10,000 issue comments\n +\n 10 = 10 followers\n\n= 22,060 total nodes
\n\n## Zeitlimits\n\nWenn GitHub mehr als 10 Sekunden benötigt, um eine API-Anfrage zu verarbeiten, wird GitHub die Anfrage beenden, und Sie erhalten eine Timeout-Antwort sowie eine Meldung mit dem Hinweis, dass „Wir konnten nicht rechtzeitig auf Ihre Anfrage antworten“.\n\nWenn dies geschieht, erhalten Sie möglicherweise entweder einen `502`- oder einen `504`-Statuscode. Beide Statuscodes weisen darauf hin, dass Ihre Anfrage das Zeitlimit überschritten hat.\n\nGitHub behält sich das Recht vor, das Timeoutfenster zu ändern, um die Geschwindigkeit und Zuverlässigkeit der API zu schützen.\n\nDu kannst den Status der GraphQL-API bei [githubstatus.com](https://www.githubstatus.com/) überprüfen, um zu ermitteln, ob das Timeout aufgrund eines Problems mit der API aufgetreten ist. Sie können auch versuchen, Ihre Anfrage zu vereinfachen oder ihre Anfrage später zu testen. Tipps zur Verbesserung der Abfrageleistung finden Sie unter [Abfrageoptimierungsstrategien](#query-optimization-strategies).\n\nWenn für eine deiner API-Anforderungen ein Timeout auftritt, werden zusätzliche Punkte von deiner primären Ratenbegrenzung für die nächste Stunde abgezogen, um die Geschwindigkeit und Zuverlässigkeit der API zu schützen.\n\n## Andere Ressourcengrenzwerte\n\nUm die Geschwindigkeit und Zuverlässigkeit der API zu schützen, GitHub erzwingt auch andere Ressourcenbeschränkungen. Wenn Ihre GraphQL-Abfrage zu viele Ressourcen verbraucht, GitHub beendet die Anforderung und gibt Teilergebnisse zusammen mit einem Fehler zurück, der angibt, dass Ressourcengrenzwerte überschritten wurden.\n\n**Beispiele für Abfragen, die Ressourcengrenzwerte überschreiten können:**\n\n* Anfordern von Tausenden von Objekten oder tief geschachtelten Beziehungen in einer einzelnen Abfrage\n* Verwenden großer `first`- oder `last`-Argumente gleichzeitig in mehreren Verbindungen\n* Abrufen umfangreicher Details für jedes Objekt, beispielsweise alle Kommentare, Reaktionen und zugehörigen Probleme für die jeweiligen Repositories.\n\n## Strategien zur Abfrageoptimierung\n\n* **Anzahl der Objekte begrenzen**: Verwende kleinere Werte für `first`- oder `last`-Argumente, und paginiere durch Ergebnisse.\n* **Abfragetiefe reduzieren**: Vermeide es, tief geschachtelte Objekte anzufordern, es sei denn, es ist erforderlich.\n* **Ergebnisse filtern**: Verwende Argumente, um Daten zu filtern und nur das zurückzugeben, was du benötigst.\n* **Große Abfragen aufteilen**: Unterteile komplexe Abfragen in mehrere einfachere Abfragen.\n* **Nur erforderliche Felder anfordern**: Wähle nur die benötigten Felder aus, anstatt alle verfügbaren Felder anzufordern.\n\nDurch Befolgen dieser Strategien kannst du die Wahrscheinlichkeit verringern, dass Ressourcengrenzwerte erreicht werden, und die Leistung und Zuverlässigkeit deiner API-Anforderungen verbessern."}