Persist and use truncated note diffs instead requesting Gitaly in a N+1 manner on MR page
What does this MR do?
Creates a new table to persist a truncated diff (i.e. get rid of the diff below every discussion comment and persist it). This relation is a simple 1-1 with notes
.
This is a similar approach of GitHub's diff_hunk
.
Why was this MR needed?
We request Gitaly in a N+1 manner to build the discussion diffs. Once the diffs are from different revisions, it's hard to make a single request to the service in order to build the whole response.
With this change we solve this problem and simplify a lot fetching this piece of data.
Statistics
On MR with ~15 discussions on diffs:
Before:
-
125ms
submitting51
Gitaly RPC calls -
24ms
submitting52
PG queries
After:
-
52ms
submitting15
Gitaly RPC calls -
25ms
submitting53
PG queries
This means we're now submitting 15 requests where we were submiting 51 before. We can also see a 140% improvement on RPC timing.
Does this MR meet the acceptance criteria?
-
Changelog entry added, if necessary -
Documentation created/updated -
API support added -
Tests added for this feature/bug - Conform by the code review guidelines
-
Has been reviewed by a Backend maintainer
-
-
Conform by the merge request performance guides -
Conform by the style guides -
If you have multiple commits, please combine them into a few logically organized commits by squashing them -
Internationalization required/considered -
End-to-end tests pass ( package-and-qa
manual pipeline job)
What are the relevant issue numbers?
Closes #45190 (closed)
Edited by Oswaldo Ferreira