Peek's `Peek.request_id` method doesn't work well with a multi-threaded
server and concurrent requests, because requests can 'steal' another
request's ID, or unset it before it was due.
The upstream change resolves this; the commit here is just to ensure
that GitLab works with that upstream change, mostly by not using
`Peek.request_id` any more (as the method doesn't exist).
This change adds Distributed Tracing support for two new types of events
1. Redis Calls
1. ActiveSupport (Rails) Caching Operations
The intention is to help application developers and infrastructure
SREs to understand the pressure that caching operations can have on
the application when running at scale.
The Redis and Caching spans can be viewed in the Jaeger UI by clicking
the "Trace" link in the performance bar when running on GDK.
These were disabled in production mode, but that also broke the rest of
the performance bar. As they were only enabled in development mode, we
can just remove them for now.
This is the first step in providing a fault-tolerant and distributed
Redis caching store. We disable compression to avoid introducing a
change that could have an adverse effect in production.
Note that we won't be able to take advantage of the fault-tolerance and
distributed features yet until we solve
https://gitlab.com/gitlab-org/gitlab-ce/issues/64829.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/64794
1. The output isn't great. It can be hard to find hotspots and, even
when you do find them, to find why those are hotspots.
2. It uses some jQuery-specific frontend code which we can remove now
that we don't have this any more.
3. It's only possible to profile the initial request, not any subsequent
AJAX requests.
This means we have one less Net::HTTP monkeypatch.
sham_rack cannot handle IPv6 addresses which means it breaks Net::HTTP
connections because it monkey-patches Net::HTTP
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.
Bootsnap speeds up Rails loading and now ships by default with Rails 5.2
apps. We should promote this to a default gem and test it out in
production. This will also make it possible for the Helm Charts to take
advantage of this.
It appears that Bootsnap with Rails 5.2.3 and all the GitLab CE gems
loads fine on an ARM platform now, so it's possible that
https://gitlab.com/gitlab-org/gitlab-ce/issues/34799 has been resolved.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/45230
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
The configuration is currently only specified in CI, by moving it into
`.mdlrc` we get immediate feedback locally in supported editors.
To ensure `mdl` is available it's also added to the `Gemfile`, though
CI will still use the version installed in the `gitlab-docs-lint` image.