gitlab-org--gitlab-foss/app/views/peek/_bar.html.haml

- return unless performance_bar_enabled?

#js-peek{ data: { env: Peek.env,
         request_id: peek_request_id,
         stats_url: ENV.fetch('GITLAB_PERFORMANCE_BAR_STATS_URL', ''),
         peek_url: "#{peek_routes_path}/results" },
         class: Peek.env }
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-27 07:40:44 -04:00			`- return unless performance_bar_enabled?`
Show Ajax requests in performance bar 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. 2018-03-19 15:06:09 -04:00
			`#js-peek{ data: { env: Peek.env,`
Fix Peek on Puma 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). 2019-08-26 09:57:59 -04:00			`request_id: peek_request_id,`
Add latest changes from gitlab-org/gitlab@master 2021-02-18 07:09:34 -05:00			`stats_url: ENV.fetch('GITLAB_PERFORMANCE_BAR_STATS_URL', ''),`
Remove line profiler from performance bar 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. 2019-07-24 07:37:05 -04:00			`peek_url: "#{peek_routes_path}/results" },`
Show Ajax requests in performance bar 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. 2018-03-19 15:06:09 -04:00			`class: Peek.env }`