diff options
author | Stan Hu <stanhu@gmail.com> | 2019-08-22 00:19:44 -0700 |
---|---|---|
committer | Stan Hu <stanhu@gmail.com> | 2019-08-22 22:28:47 -0700 |
commit | e24b9c2502613cc0df5b2a676236d1c36c02bca4 (patch) | |
tree | 8384f8dbb4fa2ca6ebebed3cfd774e81371a859f /changelogs | |
parent | ba67965ac5386164a38acda32ff4e547e61b0376 (diff) | |
download | gitlab-ce-e24b9c2502613cc0df5b2a676236d1c36c02bca4.tar.gz |
Eliminate Gitaly N+1 queries with notes APIsh-eliminate-gitaly-nplus-one-notes
Similar to https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31834,
we see that in https://gitlab.com/gitlab-org/gitlab-ce/issues/65957
there can be hundreds, even thousands, of Gitaly requests in the
`/api/:version/projects/:id/merge_requests/:noteable_id/notes` endpoint.
Previously, the API to retrieve notes generated hundreds of Gitaly calls
to determine whether a system note should be shown to the user. It did
this by:
1. Rendering the Markdown
2. Extracting cross-references from the Markdown
3. Issuing a Gitaly `FindCommit` RPC for every reference to validate
that the commit exists.
The last step is unnecessary because we don't need to display a commit
if the user doesn't have access to the project in the first place.
`RendersNotes#prepare_notes_for_rendering` is already used in
`MergeRequestsController`, which is why we don't see N+1 Gitaly calls
there. We use it here to optimize the note redaction process.
Diffstat (limited to 'changelogs')
-rw-r--r-- | changelogs/unreleased/sh-eliminate-gitaly-nplus-one-notes.yml | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/changelogs/unreleased/sh-eliminate-gitaly-nplus-one-notes.yml b/changelogs/unreleased/sh-eliminate-gitaly-nplus-one-notes.yml new file mode 100644 index 00000000000..00523f53dd7 --- /dev/null +++ b/changelogs/unreleased/sh-eliminate-gitaly-nplus-one-notes.yml @@ -0,0 +1,5 @@ +--- +title: Eliminate Gitaly N+1 queries with notes API +merge_request: 32089 +author: +type: performance |