In dev environments, Sidekiq was encountering the message:
Circular dependency detected while autoloading constant Gitlab::Profiler
This saves some overhead during normal usage.
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
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 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.
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.
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
Since Redis timings appear to be increasing in production, this change
makes it easier to see what exactly which queries are being called and
where.
This is done by prepending modules in peek-redis to store the call
details.
This commit redact values for all SET commands (e.g. HMSET, GETSET,
etc.).
This change is a fairly straightforward refactor to extract the tracing
and correlation-id code from the gitlab rails codebase into the new
LabKit-Ruby project.
The corresponding import into LabKit-Ruby was in
https://gitlab.com/gitlab-org/labkit-ruby/merge_requests/1
The code itself remains very similar for now.
Extracting it allows us to reuse it in other projects, such as
Gitaly-Ruby. This will give us the advantages of correlation-ids and
distributed tracing in that project too.
Jaeger is a distributed tracing tool. This change adds a "Tracing" link
to the performance bar to directly link to a current request in Jaeger.
This is useful for two reasons: 1 - it provides affordance to developers
that the distributed tracing tool is available, so that it can quickly
be discovered. 2 - it allows developers to quickly find a specific trace
without having to manually navigate to a second user-interface.
But first, rewrite the performance bar in Vue:
1. Remove the peek-host gem and replace it with existing code. This also allows
us to include the host in the JSON response, rather than in the page HTML.
2. Leave the line profiler parts as here-be-dragons: nicer would be a separate
endpoint for these, so we could use them on Ajax requests too.
3. The performance bar is too fiddly to rewrite right now, so apply the same
logic to that.
Then, add features! All requests made through Axios are able to be tracked. To
keep a lid on memory usage, only the first two requests for a given URL are
tracked, though. Each request that's tracked has the same data as the initial
page load, with the exception of the performance bar and the line profiler, as
explained above.
