Extend the Performance Bar with a button to profile the endpoint
Goal
The goal is to extend the Performance Bar with a button, which when clicked, will reload the page with profiling enabled and render the results in a flamegraph.
We already have all the building blocks in place:
- We already support the above functionality, but it is hidden behind a not-very-accessible interface, which is to manually add a "secret" query parameter: https://docs.gitlab.com/ee/development/profiling.html#speedscope-flamegraphs. A better interface would be to use the Performance Bar itself to offer that option.
- The backend for this is implemented in a Rack middleware: https://gitlab.com/gitlab-org/gitlab/blob/34a847aa1d2969f2b46a89120b318c2cfd802897/lib/gitlab/middleware/speedscope.rb
- The frontend is a Vue component: https://gitlab.com/gitlab-org/gitlab/blob/d6b85a6ecd5626b8f7146a7af76ff5521233a636/app/assets/javascripts/performance_bar/components/performance_bar_app.vue
MVC / completion criteria
- A button or link replaces the manually entered query parameter
- Documentation is updated, maybe a screenshot would be nice
🤓
References
- speedscope - visualizes profiling data from various sources
- stackprof - the Ruby profiler we most commonly use
- !61332 (merged) could be a useful example for how to extend Performance Bar features.
Stretch goals
If time allows, I think it would be nice to consider the following improvements:
- The current implementation only allows pulling profiles based on wall time (it uses
stackprof
). It would be nice to have the option to pull acpu
orobject
profile instead. See https://docs.gitlab.com/ee/development/performance.html#production for which modes are supported. - We have an alternative way of profiling worker processes, which is to sample CPU or object allocations over time for a given worker process (Puma or Sidekiq): https://gitlab.com/gitlab-org/gitlab/blob/627065cea6f114d3093eaf853bcfbd9f5c14f85d/lib/gitlab/stack_prof.rb. This currently requires a developer to have access to the given node and signal the process being profiled. Can we think of/propose (not necessarily implement) a solution for how we can unify all of these different ways to profile our app?
Edited by Matthias Käppler