Límite de tasa principal
GraphQL API asigna puntos a cada consulta y limita los puntos que puede usar dentro de un período de tiempo específico. Este límite ayuda a evitar ataques por denegación de servicio y abuso, y garantiza que la API siga estando disponible para todos los usuarios.
REST API también tiene un límite de volumen principal independiente. Para más información, consulta Límites de tasa de la API REST.
Generalmente, puede calcular su límite principal de velocidad para la API GraphQL en función de su método de autenticación.
-
_Para los usuarios_: 5000 puntos por hora por usuario. Esto incluye las solicitudes realizadas con un personal access token, así como las solicitudes realizadas por un GitHub App o OAuth app en nombre de un usuario que autorizó la app. Las solicitudes realizadas en nombre de un usuario por una GitHub App que pertenece a una organización de GitHub Enterprise Cloud tienen un límite de tasa más alto de 10 000 puntos por hora. De forma parecida, las solicitudes realizadas en su nombre por una OAuth app que sea propiedad de o aprobada por una organización de GitHub Enterprise Cloud tienen un límite de tasa más alto de 10,000 puntos por hora, si usted es miembro de dicha organización de GitHub Enterprise Cloud. -
_Para las instalaciones de GitHub App que no sean en una GitHub Enterprise Cloud organización o empresa_: 5000 puntos por hora por instalación. Las instalaciones que tienen más de 20 repositorios reciben otros 50 puntos adicionales por hora para cada repositorio. Las instalaciones que se encuentran en una organización que tienen más de 20 usuarios reciben otros 50 puntos por hora para cada usuario. El límite de tasa no puede superar los 12,500 puntos por hora. El límite de tasa para los tokens de acceso de usuario (en lugar de los tokens de acceso de instalación) viene determinado por el límite de tasa principal para los usuarios. -
_Para las instalaciones de GitHub App en una GitHub Enterprise Cloud organización o empresa_: 10 000 puntos por hora por instalación. El límite de tasa para los tokens de acceso de usuario (en lugar de los tokens de acceso de instalación) viene determinado por el límite de tasa principal para los usuarios. -
_Para OAuth apps_: 5000 puntos por hora o 10 000 puntos por hora si la app es propiedad de una organización GitHub Enterprise Cloud. Esto solo se aplica cuando la app usa su id. de cliente y secreto de cliente para solicitar datos públicos. El límite de volumen para tokens de acceso de OAuth generados por una OAuth app vienen definidos por los límites de volumen principales de los usuarios. -
_Para `GITHUB_TOKEN` en flujos de trabajo GitHub Actions_: 1000 puntos por hora por repositorio. Para las solicitudes a recursos que pertenecen a una cuenta empresarial en GitHub.com, el límite es de 15 000 puntos por hora por repositorio.
Puede comprobar el valor de punto de una consulta o calcular el valor de punto esperado, tal como se describe en las secciones siguientes. La fórmula para calcular puntos y el límite de frecuencia están sujetos a cambios.
Comprobación del estado de su límite de tasa principal
Puede usar los encabezados que se envían con cada respuesta para determinar el estado actual de su límite de tasa primario.
| Nombre de encabezado | Descripción |
|---|---|
x-ratelimit-limit | Cantidad máxima de puntos que puede usar por hora. |
x-ratelimit-remaining | Cantidad de puntos que quedan en la ventana de límite de tasa actual. |
x-ratelimit-used | Número de puntos que ha usado en la ventana de límite de velocidad actual. |
x-ratelimit-reset | Hora a la que se restablece la ventana de límite de volumen actual en segundos de época UTC. |
x-ratelimit-resource | Recurso de límite de volumen respecto al que se cuenta la solicitud. En el caso de las solicitudes de GraphQL, siempre será graphql. |
También puede consultar el objeto rateLimit para comprobar su límite de tasa. Cuando sea posible, debe usar los encabezados de respuesta de límite de volumen en lugar de consultar la API para comprobar el límite de volumen.
query {
viewer {
login
}
rateLimit {
limit
remaining
used
resetAt
}
}
| Campo | Descripción |
|---|---|
limit | Cantidad máxima de puntos que puede usar por hora. |
remaining | Cantidad de puntos que quedan en la ventana de límite de tasa actual. |
used | Número de puntos que ha usado en la ventana de límite de velocidad actual. |
resetAt | Hora a la que se restablece la ventana de límite de volumen actual en segundos de época UTC. |
Devolución del valor de punto de una consulta
Puede devolver el valor de punto de una consulta consultando el campo cost en el objeto rateLimit:
query {
viewer {
login
}
rateLimit {
cost
}
}
Predicción del valor de punto de una consulta
También puede calcular de forma aproximada el valor de punto de una consulta antes de realizar la consulta.
- Agrega la cantidad de solicitudes requeridas para completar cada conexión única en la llamada. Suponga que todas las solicitudes alcanzarán los límites de argumentos
firstolast. - Divida la cantidad entre 100 y redondee el resultado al número entero más próximo para obtener el valor de punto final agregado. Este paso normaliza números grandes.
Nota:
El valor mínimo de punto de una llamada a GraphQL API es 1.
Aquí se muestra una consulta y cálculo de puntaje de ejemplo:
query {
viewer {
login
repositories(first: 100) {
edges {
node {
id
issues(first: 50) {
edges {
node {
id
labels(first: 60) {
edges {
node {
id
name
}
}
}
}
}
}
}
}
}
}
}
Esta consulta requiere de 5,101 solicitudes para completarse:
- Aunque se devuelven 100 repositorios, la API se tiene que conectarse a la cuenta del visor una vez para obtener la lista de repositorios. Por lo tanto, las solicitudes de repositorios = 1
- Aunque se devuelven 50 incidencias, la API tiene que conectarse a cada uno de los 100 repositorios para obtener la lista de problemas. Por lo tanto, solicitudes de problemas = 100
- Aunque se devuelven 60 etiquetas, la API tiene que conectarse a cada uno de los 5000 problemas potenciales totales para obtener la lista de etiquetas. Por lo tanto, solicitudes de etiquetas = 5000
- Total = 5101
Si lo dividimos entre 100 y lo redondeamos, obtenemos la puntuación final de la consulta: 51.
Límites de tasa secundarios
Además de los límites de volumen principales, GitHub aplica límites de volumen secundarios para evitar el abuso y mantener la API disponible para todos los usuarios.
Puedes encontrar un límite de tasa secundario si:
-
_Haces demasiadas solicitudes simultáneas._ No se permiten más de 100 solicitudes simultáneas. Este límite se comparte entre la API de REST y la API de GraphQL. -
_Haces demasiadas solicitudes a un único punto de conexión por minuto._ No se permiten más de 900 puntos por minuto para los puntos de conexión de la API de REST y no se permiten más de 2000 puntos por minuto para el punto de conexión de la API de GraphQL. Para más información sobre los puntos, consulta [Cálculo de puntos para el límite secundario de tasa](#calculating-points-for-the-secondary-rate-limit). -
_Haces demasiadas solicitudes por minuto._ No se permiten más de 90 segundos de tiempo de CPU por 60 segundos de tiempo real. No más de 60 segundos de este tiempo de CPU puede ser para la API de GraphQL. Puedes calcular aproximadamente el tiempo de CPU midiendo el tiempo de respuesta total de las solicitudes de API. -
_Realice demasiadas solicitudes que consuman recursos de proceso excesivos en un breve período de tiempo._ -
_Creas demasiado contenido en GitHub en un corto período de tiempo._ En general, no se permiten más de 80 solicitudes de generación de contenido por minuto y no se permiten más de 500 solicitudes de generación de contenido por hora. Algunos puntos de conexión tienen límites de creación de contenido inferiores. Entre los límites de creación de contenido se incluyen las acciones realizadas en la interfaz web de GitHub, así como a través de la API de REST y la API de GraphQL. -
_Realice demasiadas solicitudes de token de acceso de OAuth en un breve período de tiempo._ No se permiten más de 2000 solicitudes de token de acceso de OAuth por hora para GitHub Apps y OAuth apps.
Estos límites de tasa secundarios están sujetos a cambios sin previo aviso. También puedes encontrarte con un límite de tasa secundario por motivos no revelados.
Calcular puntos para el límite de tasa secundario
Algunos límites secundarios de tasa se determinan por los valores de puntos de las solicitudes. En el caso de solicitudes de GraphQL, estos valores de punto son independientes de los cálculos de valor de punto para el límite de volumen principal.
| Solicitud | Puntos |
|---|---|
| Solicitudes de GraphQL sin mutaciones | 1 |
| Solicitudes de GraphQL con mutaciones | 5 |
La mayoría de las solicitudes de la API de REST GET, HEAD y OPTIONS | 1 |
La mayoría de las solicitudes de la API REST POST, PATCH, PUT o DELETE | 5 |
Algunos puntos de conexión de la API de REST tienen un coste de punto diferente que no se comparte públicamente.
Superación del límite de frecuencia
Si supera el límite de volumen principal, el estado de la respuesta seguirá siendo 200, pero recibirá un mensaje de error y el valor del encabezado x-ratelimit-remaining será 0. No debes reintentar la solicitud hasta después de la hora especificada por el encabezado x-ratelimit-reset.
Si supera una limitación de volumen secundaria, el estado de respuesta será 200 o 403 y recibirá un mensaje de error que indicará que ha alcanzado un límite de volumen secundaria. Si el encabezado de respuesta retry-after está presente, no debes reintentar la solicitud hasta que hayan transcurrido los segundos indicados. Si el encabezado de x-ratelimit-remaining es 0, no debes reintentar la solicitud hasta después de la hora, en segundos de época UTC, especificados por el encabezado de x-ratelimit-reset. De lo contrario, espere al menos un minuto antes de volver a intentarlo. Si la solicitud sigue produciendo un error debido a una limitación de volumen secundaria, espere un período de tiempo exponencialmente creciente entre reintentos y genere un error después de un número específico de reintentos.
Continuar realizando solicitudes mientras tiene una limitación de volumen puede dar lugar a la prohibición de la integración.
Mantenerse bajo el límite de tasa
Para evitar superar un límite de volumen, debe pausar al menos 1 segundo entre solicitudes mutativas y evitar solicitudes simultáneas.
También debe suscribirse a eventos de webhook en lugar de sondear la API para obtener datos. Para más información, consulta Documentación de webhooks.
También puedes transmitir el registro de auditoría para ver las solicitudes de API. Esto puede ayudarte a solucionar problemas de integraciones que superan el límite de volumen. Para más información, consulta Streaming del registro de auditoría de su empresa.
Límite de nodos
Para pasar la validación del esquema, todas las llamadas de la API de GraphQL deben cumplir estos estándares:
- Los clientes deben proporcionar un argumento
firstolasten cualquier conexión. - Los valores de
firstylastdeben estar comprendidos entre 1 y 100. - Las llamadas individuales no pueden solicitar más de un total de 500 000 nodos.
Calcular los nodos en una llamada
Estos dos ejemplos te muestran cómo calcular los nodos totales en una llamada.
-
Consulta simple:
query { viewer { repositories(first: 50) { edges { repository:node { name issues(first: 10) { totalCount edges { node { title bodyHTML } } } } } } } }Cálculo:
50 = 50 repositories + 50 x 10 = 500 repository issues = 550 total nodes
-
Consulta compleja:
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 } } } } }Cálculo:
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
Tiempos de expiración
Si GitHub tarda más de 10 segundos en procesar una solicitud de API, GitHub finalizará la solicitud y recibirá una respuesta de tiempo de espera y un mensaje que informa de que "No hemos podido responder a la solicitud a tiempo".
se reserva el derecho de cambiar la ventana de tiempo de espera para proteger la velocidad y confiabilidad de la API.
Puede comprobar el estado de la API de GraphQL en githubstatus.com para determinar si el tiempo de espera excedido se debe a un problema con la API. También puede intentar simplificar la solicitud o probar la solicitud más adelante. Por ejemplo, si solicita un gran número de objetos en una sola solicitud, puede intentar solicitar menos objetos divididos en varias consultas.
Si se produce un tiempo de espera para cualquiera de las solicitudes de API, se deducirán puntos adicionales del límite de frecuencia principal durante la próxima hora para proteger la velocidad y la confiabilidad de la API.
Otros límites de recursos
Para proteger la velocidad y confiabilidad de la API, GitHub también aplica otras limitaciones de recursos. Si la consulta de GraphQL consume demasiados recursos, GitHub finalizará la solicitud y devolverá resultados parciales junto con un error que indica que se superaron los límites de recursos.
**Ejemplos de consultas que pueden superar los límites de recursos:**
- Solicitar miles de objetos o relaciones profundamente anidadas en una sola consulta.
- Usar argumentos
firstolastgrandes en varias conexiones simultáneamente. - Capturar detalles exhaustivos de cada objeto, como todos los comentarios, reacciones e incidencias relacionados de cada repositorio.
Estrategias de optimización de consultas
-
**Limitación del número de objetos**: usa valores más pequeños para los argumentos `first` o `last`, y pagina los resultados. -
**Reducción de la profundidad de consulta**: evita solicitar objetos profundamente anidados a menos que sea necesario. -
**Filtrado de los resultados**: usa argumentos para filtrar datos y devolver solo lo que necesitas. -
**División de consultas grandes**: divide las consultas complejas en varias consultas más sencillas. -
**Solicitud de los campos obligatorios exclusivamente**: selecciona solo los campos que necesites, en lugar de solicitar todos los campos disponibles.
Si sigues estas estrategias, puedes reducir la probabilidad de alcanzar los límites de recursos y mejorar el rendimiento y la confiabilidad de las solicitudes de API.