Cache Zoekt responses
What does this MR do and why?
The Zoekt integration currently requests 5,000 results for one search in order for it to produce deterministic results. After that, we only take one page worth of results (20) and discard the rest (up to 4,980), which is quite wasteful. I think we can do better than that.
Given this peculiarity I've decided to add a Zoekt response caching layer. It writes first 10 pages worth of parsed responses to Redis caching server. That means that for a heavy request like test in gitlab-org, which might take up to 3.5s, we'd only make one request to Zoekt and save 3.5s per page for pages 2-10 (I think it should be enough for most users for now).
Also, as a side effect, we'd reduce puma memory consumption.
I'm not using Rails.cache because we need to save multiple keys (up to 10) in one request to Redis (redis.multi).
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
| Before | After |
|---|---|
 |
 |
 |
 |
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
- Enable Zoekt
- Enable caching by executing and restart rails
touch tmp/caching-dev.txt gdk restart rails-web - Enable performance bar
- Search in zoekt-enabled project and go pages 1,5,8,11+ and note the zoekt request timings
- Enable the caching FF
Feature.enable(:zoekt_cache_search_responses) - Wait for a minute and go over the same pages again. This time you should only see Zoekt requests on pages 1 and 11+
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.