Commit graph

14 commits

Author SHA1 Message Date
GitLab Bot
79f759cc14 Add latest changes from gitlab-org/gitlab@master 2021-09-21 18:11:18 +00:00
GitLab Bot
07e0fae35c Add latest changes from gitlab-org/gitlab@master 2021-08-06 15:10:05 +00:00
GitLab Bot
9e16447c7c Add latest changes from gitlab-org/gitlab@master 2021-07-28 06:09:29 +00:00
GitLab Bot
d4194db620 Add latest changes from gitlab-org/gitlab@master 2021-06-04 15:10:25 +00:00
GitLab Bot
0ae8428c8e Add latest changes from gitlab-org/gitlab@master 2021-05-11 21:10:21 +00:00
GitLab Bot
1d041b2968 Add latest changes from gitlab-org/gitlab@master 2021-03-24 18:09:31 +00:00
GitLab Bot
fdb953945d Add latest changes from gitlab-org/gitlab@master 2021-03-05 12:08:55 +00:00
GitLab Bot
ec18750aa8 Add latest changes from gitlab-org/gitlab@master 2020-10-05 18:08:51 +00:00
GitLab Bot
fb73ca3398 Add latest changes from gitlab-org/gitlab@master 2019-12-27 15:08:16 +00:00
Sean McGivern
18018bcd41 Fix performance bar thresholds
These were written in seconds but are supposed to be in
milliseconds. The total Gitaly time was wrong for the same reason.
2019-09-03 13:13:36 +01:00
Rémy Coutable
b7398bc1fd Merge branch 'fix-peek-on-puma' into 'master'
Fix Peek on Puma

Closes #66528

See merge request gitlab-org/gitlab-ce!32213
2019-09-02 08:43:21 +00:00
Sean McGivern
f9c456bd0c Make performance bar enabled checks consistent
Previously, we called the `peek_enabled?` method like so:

    prepend_before_action :set_peek_request_id, if: :peek_enabled?

Now we don't have a `set_peek_request_id` method, so we don't need that
line. However, the `peek_enabled?` part had a side-effect: it would also
populate the request store cache for whether the performance bar was
enabled for the current request or not.

This commit makes that side-effect explicit, and replaces all uses of
`peek_enabled?` with the more explicit
`Gitlab::PerformanceBar.enabled_for_request?`. There is one spec that
still sets `SafeRequestStore[:peek_enabled]` directly, because it is
contrasting behaviour with and without a request store enabled.

The upshot is:

1. We still set the value in one place. We make it more explicit that
   that's what we're doing.
2. Reading that value uses a consistent method so it's easier to find in
   future.
2019-08-28 17:25:02 +01:00
Sean McGivern
23c1cfcc11 Return warnings for performance bar from backend
For each DetailedView subclass, we add a `warnings` array to:

1. The top-level response.
2. Each individual call under the `details` key.

We use the `.thresholds` hash on the DetailedView to determine what's a
warning. If that hash is empty (the default), then the warnings array
will always be empty.
2019-08-28 16:39:33 +01:00
Sean McGivern
ad1c71663f Replace peek-pg with our own implementation
This uses an ActiveRecord subscriber to get queries and calculate the
total query time from that. This means that the total will always be
consistent with the queries in the table. It does however mean that we
could potentially miss some queries that don't go through ActiveRecord.

Making this change also allows us to unify the response JSON a little
bit, making the frontend slightly simpler as a result.
2019-07-26 14:37:26 +01:00