Commit graph

8 commits

Author SHA1 Message Date
GitLab Bot
c59765a50a Add latest changes from gitlab-org/gitlab@master 2020-06-24 18:09:03 +00:00
GitLab Bot
6b9d3a4e83 Add latest changes from gitlab-org/gitlab@master 2020-01-29 18:08:47 +00:00
GitLab Bot
d10a462fed Add latest changes from gitlab-org/gitlab@master 2019-12-16 12:07:43 +00:00
Ash McKenzie
124bad7bd8
Use stub_rails_env for Rails.env stubbing
RailsHelpers.stub_rails_env takes care of
stubbing Rails.env
2019-09-05 12:54:03 +10:00
Thong Kuah
8c42a0eac0 Add frozen_string_literal to lib part 2
Using the sed script from
https://gitlab.com/gitlab-org/gitlab-ce/issues/59758
2019-08-23 00:15:24 +12:00
Dylan Griffith
2e216dd43b Do not count rails sql cache as queries in query limiting 2018-02-21 16:27:05 +11:00
Yorick Peterse
e3bd674e81
Remove Sentry reporting for query limiting
Using Sentry, while useful, poses two problems you have to choose from:

1. All errors are reported separately, making it easy to create issues
   but also making it next to impossible to see other errors (due to the
   sheer volume of threshold errors).

2. Errors can be grouped or merged together, reducing the noise. This
   however also means it's (as far as I can tell) much harder to
   automatically create GitLab issues from Sentry for the offending
   controllers.

Since both solutions are terrible I decided to go with a third option:
not using Sentry for this at all. Instead we'll investigate using
Prometheus alerts and Grafana dashboards for this, which has the added
benefit of being able to more accurately measure the behaviour over
time.

Note that throwing errors in test environments is still enabled, and
whitelisting is still necessary to prevent that from happening (and that
in turn still requires that developers create issues).
2018-02-13 17:26:59 +01:00
Yorick Peterse
cca61980d5
Track and act upon the number of executed queries
This ensures that we have more visibility in the number of SQL queries
that are executed in web requests. The current threshold is hardcoded to
100 as we will rarely (maybe once or twice) change it.

In production and development we use Sentry if enabled, in the test
environment we raise an error. This feature is also only enabled in
production/staging when running on GitLab.com as it's not very useful to
other users.
2018-02-01 17:00:46 +01:00