mirror of
https://github.com/sourcegraph/sourcegraph.git
synced 2026-02-06 17:51:57 +00:00
0236f9e240
Looks like GitHub.com has become more lenient, or transparent on their docs page: https://docs.github.com/en/rest/overview/rate-limits-for-the-rest-api?apiVersion=2022-11-28#about-secondary-rate-limits. The paragraph about single request per token is gone from this page! Instead, they describe secondary rate limits quite well now: ``` You may encounter a secondary rate limit if you: Make too many concurrent requests. No more than 100 concurrent requests are allowed. This limit is shared across the REST API and GraphQL API. Make too many requests to a single endpoint per minute. No more than 900 points per minute are allowed for REST API endpoints, and no more than 2,000 points per minute are allowed for the GraphQL API endpoint. For more information about points, see "Calculating points for the secondary rate limit." Make too many requests per minute. No more than 90 seconds of CPU time per 60 seconds of real time is allowed. No more than 60 seconds of this CPU time may be for the GraphQL API. You can roughly estimate the CPU time by measuring the total response time for your API requests. Create too much content on GitHub in a short amount of time. In general, no more than 80 content-generating requests per minute and no more than 500 content-generating requests per hour are allowed. Some endpoints have lower content creation limits. Content creation limits include actions taken on the GitHub web interface as well as via the REST API and GraphQL API. ``` So the limit is no longer 1, it is roughly 100. Well, that depends on what APIs you’re calling, but whatever. Strangely, in the best practices section they still say that 1 request is advised, I followed up with a support ticket with GitHub to clarify. ### Outcome They said 100 is the limit but for certain requests the number can be lower. This doesn't convince us (team source) that it's worth keeping it. Besides, they also document that they return a Retry-After header in this event and we already handle that with retries (if the retry is not in the too distant future). So.. I want to say that this is “no different than any other API” at this point. Sure, there are some limits that they enforce, but that’s true for all the APIs. The 1-concurrency only one was quite gnarly which totally justified the GitHub-Proxy and now the redis-based replacement IMO, but I don’t think with the recent changes here it does warrant a github.com-only special casing (pending talking to GitHub about that docs weirdness), and instead of investing into moving the concurrency lock into the transport layer, I think we should be fine dropping it altogether. |
||
|---|---|---|
| .. | ||
| command | ||
| definitions | ||
| grafanaclient | ||
| monitoring | ||
| .gitattributes | ||
| BUILD.bazel | ||
| CODENOTIFY | ||
| generate_config_test.sh | ||
| go.mod | ||
| go.sum | ||
| main.go | ||
| README.md | ||
Sourcegraph monitoring generator
This page documents usage (running the generator) and development (of the generator itself). For background and feature documentation, see the generator overview. To learn about how to find, add, and use monitoring, see the Sourcegraph observability developer guide.
Usage
From this directory:
go generate ./...
Logging output supports the Sourcegraph log level flags.
Other configuration options can be customized via flags declared in main.go.
Development
The Sourcegraph monitoring generator consists of three components:
- The main program - this is the primary entrypoint to the generator.
- Definitions, defined in the top-level
monitoring/definitionspackage. This is where the all service monitoring definitions lives. If you are editing monitoring, this is probably where you want to look - see the Sourcegraph observability developer guide. - Generator, defined in the nested
monitoring/monitoringpackage package. This is where the API for service monitoring definitions is defined, as well as the generator code that provides its features.
All features and capabilities for developed for the generator should align with the Sourcegraph monitoring pillars.