Commit graph

13 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
63546c0b11 Add latest changes from gitlab-org/gitlab@master 2020-06-04 12:08:21 +00:00
GitLab Bot
21539fe9ab Add latest changes from gitlab-org/gitlab@master 2020-05-22 00:08:07 +00:00
GitLab Bot
5abd2b70c8 Add latest changes from gitlab-org/gitlab@master 2020-05-21 00:08:06 +00: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
Stan Hu
7a5c4cd0ca Fix SystemStackError when Peek bar is active with Rugged calls
Peek attempts to serialize results with `to_json`, which calls
`ActiveSupport::JSON`. If an object is passed to `to_json` that contains
instance variables, `ActiveSupport` will attempt to recursively traverse
all variables.

The problem is that we can get into an infinite loop if the instance
references to an instance that references to something else that points
back to the same instance.

To avoid this mess, we just call `to_s` on the object. It appears only
`Gitlab::Git::Repository` and `::Repository` are the culprits here.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/65404
2019-07-31 15:47:19 -07:00
Stan Hu
d7eadcc0f3 Use a base class for Peek views
Introduce a `DetailedView` base class, which is inherited by
the Gitaly, Redis, and Rugged views. This reduces code duplication.
2019-07-24 08:57:42 -07:00
Stan Hu
02a2793725 Hide Rugged data if it doesn't exist 2019-07-23 22:12:42 -07:00
Stan Hu
291df05e43 Add Rugged calls to performance bar
This will help diagnose the source of excessive I/O from Rugged
calls. To implement this, we need to obtain the full list of arguments
sent to each request method.
2019-07-23 21:38:05 -07:00
Stan Hu
9dd59df699 Fix inconsistency in Redis performance bar stats
peek-redis resets its counters at the start of an ActionController
notification (`start_processing.action_controller`), which causes it to
miss some Redis queries that precede it, such as the database load
balancer and Rack Attack queries. This produces inconsistencies in the
performance bar between the number of calls and their durations with the
actual calls in the detailed view.

We fix this by getting rid of peek-redis in favor of consolidating all
logic into the `RedisDetailed` view, which tracks Redis queries using
`RequestStore`. This has the nice property of removing thread-specific
counters as well.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/64707
2019-07-17 15:11:01 -07:00
Stan Hu
3084c37f3e Perform more redactions in Redis performance bar traces
HMSET and AUTH commands were not properly redacted. This commit
does that and adds a test.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/64309
2019-07-09 07:21:49 -07:00