Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bitbucketserver: Document rate limit change and rationale #9048

Merged
merged 4 commits into from Mar 17, 2020

Conversation

slimsag
Copy link
Member

@slimsag slimsag commented Mar 16, 2020

This PR documents the change made in #9038.

@tsenart in this commit you increased the Bitbucket Server rate limit, which is OK, but:

  1. There isn't a CHANGELOG entry. Telling folks we plan to make up to 4x the number of requests to their Bitbucket instance (and why we think this isn't an issue) is important, especially because many customers are aware of us in the past having issues with taking down / causing harm to code hosts due to excessive API requests.
  2. Even if we don't believe this will cause issues (which seems reasonable to me), we should have some documented form of recourse. This can be as simple as "If you encounter issues, please downgrade and contact support." in the CHANGELOG entry.
  3. You removed the comment explaining how we chose these limits. Anyone reading this code will feel it is arbitrary, and anyone looking at the history will think we went from something logical ("same as bitbucket cloud") to something arbitrary (explanation removed).
  4. You removed the // 120/min or 7200/hr comment, which is helpful when linking customers/users to this code as an explanation of the max we will do.

Note: I know I could've just fixed these for you more easily, my hope is this clarifies why I think this is important to communicate to our consumers.

This reverts commit 128069c.

@tsenart in this commit you increased the Bitbucket Server rate limit, which is OK, but:

1. There isn't a CHANGELOG entry. Telling folks we plan to make up to 4x the number of requests to their Bitbucket instance (and why we think this isn't an issue) is _important_, especially because many customers are aware of us in the past having issues with taking down / causing harm to code hosts due to excessive API requests.
2. Even if we don't believe this will cause issues (which seems reasonable to me), we should have some documented form of recourse. This can be as simple as "If you encounter issues, please downgrade and contact support." in the CHANGELOG entry.
3. You removed the comment explaining how we chose these limits. Anyone reading this code will feel it is arbitrary, and anyone looking at the history will think we went from something logical ("same as bitbucket cloud") to something arbitrary (explanation removed).
4. You removed the `// 120/min or 7200/hr` comment, which is helpful when linking customers/users to this code as an explanation of the max we will do.

Note: I know I could've just fixed these for you more easily, my hope is this clarifies why I think this is important to communicate to our consumers.
@slimsag
Copy link
Member Author

slimsag commented Mar 16, 2020

  • I pushed a commit with what I would do to resolve the four problems I mentioned in the PR description. You can merge this if you like. I didn't do that originally because my intent here was to communicate these problems and let you find a solution that made sense to you for solving them without prescribing any solution.
  • I sent this as a revert commit to explain that I think resolving these issues before branch release is important, but not to say I am opposed to the change. i.e. I wanted you to choose whether to revert or address these issues, because I am neither opposed nor in favor of this change (I just don't have enough confidence about the underlying numbers to be in either state). In retrospect I should've stated this to avoid coming across as upset (which really was not my intent at all)

@tsenart tsenart changed the title Revert "bitbucketserver: Increase client rate limit to 8 req/s (#9038)" bitbucketserver: Document rate limit change and rationale Mar 17, 2020
CHANGELOG.md Outdated Show resolved Hide resolved
@tsenart tsenart merged commit 07ee5aa into master Mar 17, 2020
@tsenart tsenart deleted the sg/rv-tsenert branch March 17, 2020 11:27
@@ -34,6 +34,7 @@ All notable changes to Sourcegraph are documented in this file.
- Archived repositories are excluded from search by default. Adding `archived:yes` includes archived repositories.
- Forked repositories are excluded from search by default. Adding `fork:yes` includes forked repositories.
- CSRF and session cookies now set `SameSite=None` when Sourcegraph is running behind HTTPS and `SameSite=Lax` when Sourcegraph is running behind HTTP in order to comply with a [recent IETF proposal](https://web.dev/samesite-cookies-explained/#samesitenone-must-be-secure). As a side effect, the Sourcegraph browser extension and GitLab/Bitbucket native integrations can only connect to private instances that have HTTPS configured. If your private instance is only running behind HTTP, please configure your instance to use HTTPS in order to continue using these.
- The Bitbucket Server rate limit that Sourcegraph self-imposes has been raised from 120 req/min to 480 req/min to account for Sourcegraph instances that make use of Sourcegraphs' Bitbucket Server repository permissions and campaigns at the same time (which require a larger number of API requests aginst Bitbucket). The new number is based on us consuming roughly 8% the average API request rate against at large customers' Bitbucket Server instances. [#9048](https://github.com/sourcegraph/sourcegraph/pull/9048/files)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a typo? s/aginst/against/?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Omg, I typed a typo while fixing a typo 🤦‍♂️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants