Use EventedFileUpdateChecker as file_watcher
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
:
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 |
---|---|
file_update_checker.rb
overhead can no longer be observed in the profiler:
How to set up and validate locally
- 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.
-
I have evaluated the MR acceptance checklist for this MR.