Skip to content
Snippets Groups Projects
  1. Nov 19, 2019
  2. Nov 08, 2019
  3. Oct 18, 2019
  4. Oct 17, 2019
  5. Apr 01, 2019
  6. Dec 20, 2018
  7. Nov 05, 2018
    • Yorick Peterse's avatar
      Rewrite SnippetsFinder to improve performance · d171ff60
      Yorick Peterse authored
      This completely rewrites the SnippetsFinder class from the ground up in
      order to improve its performance. The old code was beyond salvaging. It
      was complex, included various Rails 5 workarounds, comments that
      shouldn't be necessary, and most important of all: it produced a really
      poorly performing database query.
      
      As a result, I opted for rewriting the finder from scratch, instead of
      trying to patch the existing code. Instead of trying to reuse as many
      existing methods as possible, I opted for defining new methods
      specifically meant for the SnippetsFinder. This requires some extra code
      here and there, but allows us to have much more control over the
      resulting SQL queries. It is these changes that then allow us to produce
      a _much_ more efficient query.
      
      To illustrate how bad the old query was, we will use my own snippets as
      an example. Currently I have 52 snippets, most of which are global ones.
      To retrieve these, you would run the following Ruby code:
      
          user = User.find_by(username: 'yorickpeterse')
      
          SnippetsFinder.new(user, author: user).execute
      
      On GitLab.com the resulting query will take between 10 and 15 seconds to
      run, producing the query plan found at
      https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
      the total number of buffers (the sum of all shared hits) is around 185
      GB, though the real number is probably (hopefully) much lower as I doubt
      simply summing these numbers produces the true total number of buffers
      used.
      
      The new query's plan can be found at https://explain.depesz.com/s/wHdN,
      and this query takes between 10 and 100-ish milliseconds to run. The
      total number of buffers used is only about 30 MB.
      
      Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
      Unverified
      d171ff60
  8. Nov 27, 2017
  9. Aug 02, 2017
  10. Jul 27, 2017
  11. May 10, 2017
  12. Apr 30, 2017
  13. Mar 21, 2017
  14. Jan 26, 2017
  15. Dec 06, 2016
  16. Dec 02, 2016
  17. Oct 07, 2016
    • Nick Thomas's avatar
      Add markdown cache columns to the database, but don't use them yet · e94cd6fd
      Nick Thomas authored
      This commit adds a number of _html columns and, with the exception of Note,
      starts updating them whenever the content of their partner fields changes.
      
      Note has a collision with the note_html attr_accessor; that will be fixed later
      
      A background worker for clearing these cache columns is also introduced - use
      `rake cache:clear` to set it off. You can clear the database or Redis caches
      separately by running `rake cache:clear:db` or `rake cache:clear:redis`,
      respectively.
      e94cd6fd
  18. Sep 19, 2016
  19. Jun 22, 2016
  20. Jun 03, 2016
  21. Jun 01, 2016
    • Yorick Peterse's avatar
      Refactor Participable · 580d2501
      Yorick Peterse authored
      There are several changes to this module:
      
      1. The use of an explicit stack in Participable#participants
      2. Proc behaviour has been changed
      3. Batch permissions checking
      
      == Explicit Stack
      
      Participable#participants no longer uses recursion to process "self" and
      all child objects, instead it uses an Array and processes objects in
      breadth-first order. This allows us to for example create a single
      Gitlab::ReferenceExtractor instance and pass this to any Procs. Re-using
      a ReferenceExtractor removes the need for running potentially many SQL
      queries every time a Proc is called on a new object.
      
      == Proc Behaviour Changed
      
      Previously a Proc in Participable was expected to return an Array of
      User instances. This has been changed and instead it's now expected that
      a Proc modifies the Gitlab::ReferenceExtractor passed to it. The return
      value of the Proc is ignored.
      
      == Permissions Checking
      
      The method Participable#participants uses
      Ability.users_that_can_read_project to check if the returned users have
      access to the project of "self" _without_ running multiple SQL queries
      for every user.
      Unverified
      580d2501
  22. May 09, 2016
  23. Mar 11, 2016
    • Yorick Peterse's avatar
      Use ILIKE/LIKE for searching snippets · 1f5284e5
      Yorick Peterse authored
      Previously this used a regular LIKE which is case-sensitive on
      PostgreSQL. This ensures that for both PostgreSQL and MySQL the
      searching is case-insensitive similar to searching for projects.
      1f5284e5
  24. Mar 05, 2016
  25. Dec 09, 2015
  26. Jun 19, 2015
  27. Jun 10, 2015
  28. May 26, 2015
  29. Feb 12, 2015
  30. Oct 09, 2014
  31. Jun 26, 2014
  32. Apr 09, 2014
  33. Aug 21, 2013
  34. Jun 19, 2013
  35. Mar 24, 2013
  36. Jan 22, 2013
  37. Nov 19, 2012
Loading