Skip to content

Use EventedFileUpdateChecker as file_watcher

Stanislav Lashmanov requested to merge slashmanov/evented-file-updater into master

What does this MR do and why?

While validating caching of the diff file API responses here I've noticed that even the cached version takes almost 500ms to return a response. I was surprised that the flamegraph showed lower total execution times. So I dug a little bit further and profiled the entire puma worker process. I quickly found out that most of the response time was consumed by file_update_checker.rb:

image

As far as I understand it checks for every file if it has been changed since last time to hot-reload the GitLab app. And it does that for every single request.

I've discovered this solution to the issue and applied it locally. It was basically switching file_watcher to an evented mechanism which works more efficiently. It uses a listen gem underneath.

After the switch I've discovered around a 100-200ms reduction in response times for every request in development mode.

Screenshots or screen recordings

Comparison of the diffs_batch.json API 304 request for 30 files:

Before After
image image

file_update_checker.rb overhead can no longer be observed in the profiler:

image

How to set up and validate locally

  1. Open any page and compare response times with the master branch (do not forget to restart GDK)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports