Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • 12-9-stable
  • 12-7-stable
  • 12-6-stable
  • 12-8-stable
  • github/fork/Kloppi313/patch-1
  • 12-5-stable
  • 12-4-stable
  • github/fork/ramalokesh8477/master
  • 12-1-stable
  • 12-2-stable
  • 12-0-stable
  • 12-3-stable
  • 42-42-stable
  • github/fork/hussamgit398/patch-2
  • 12-3-auto-deploy-20190911
  • 12-3-auto-deploy-20190916
  • 12-3-auto-deploy-20190908
  • 12-3-auto-deploy-20190901
  • 12-3-auto-deploy-20190901-32664
  • v12.10.0.pre
  • v12.9.0
  • v12.9.0-rc42
  • v12.8.7
  • v12.8.6
  • v12.8.5
  • v12.8.4
  • v12.8.3
  • v12.6.8
  • v12.7.7
  • v12.8.2
  • v12.8.1
  • v12.9.0.pre
  • v12.8.0
  • v12.8.0-rc42
  • v12.5.10
  • v12.7.6
  • v12.6.7
  • v12.7.5
  • v12.5.9
40 results

notes_helpers.rb

  • Stan Hu's avatar
    e24b9c25
    Eliminate Gitaly N+1 queries with notes API · e24b9c25
    Stan Hu authored
    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.
    e24b9c25
    History
    Eliminate Gitaly N+1 queries with notes API
    Stan Hu authored
    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.