BigW Consortium Gitlab

  1. 23 Aug, 2017 1 commit
    • Cache the number of open issues and merge requests · 6ec53f5d
      Yorick Peterse authored
      Every project page displays a navigation menu that in turn displays the
      number of open issues and merge requests. This means that for every
      project page we run two COUNT(*) queries, each taking up roughly 30
      milliseconds on GitLab.com. By caching these numbers and refreshing them
      whenever necessary we can reduce loading times of all these pages by up
      to roughly 60 milliseconds.
      
      The number of open issues does not include confidential issues. This is
      a trade-off to keep the code simple and to ensure refreshing the data
      only needs 2 COUNT(*) queries instead of 3. A downside is that if a
      project only has 5 confidential issues the counter will be set to 0.
      
      Because we now have 3 similar counting service classes the code
      previously used in Projects::ForksCountService has mostly been moved to
      Projects::CountService, which in turn is reused by the various service
      classes.
      
      Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/36622
  2. 18 Aug, 2017 1 commit
  3. 28 Jul, 2017 1 commit
    • Merge issuable "reopened" state into "opened" · 6ef87a20
      Yorick Peterse authored
      Having two states that essentially mean the same thing is very much like
      having a boolean "true" and boolean "mostly-true": it's rather silly.
      This commit merges the "reopened" state into the "opened" state while
      taking care of system notes still showing messages along the lines of
      "Alice reopened this issue".
      
      A big benefit from having only two states (opened and closed) is that
      indexing and querying becomes simpler and more performant. For example,
      to get all the opened queries we no longer have to query both states:
      
          SELECT *
          FROM issues
          WHERE project_id = 2
          AND state IN ('opened', 'reopened');
      
      Instead we can query a single state directly, which can be much faster:
      
          SELECT *
          FROM issues
          WHERE project_id = 2
          AND state = 'opened';
      
      Further, only having two states makes indexing easier as we will only
      ever filter (and thus scan an index) using a single value. Partial
      indexes could help but aren't supported on MySQL, complicating the
      development process and not being helpful for MySQL.
  4. 07 Jul, 2017 2 commits
  5. 06 Jul, 2017 2 commits
    • Added Cop to blacklist the use of `dependent:` · 8fbbf41e
      Yorick Peterse authored
      This is allowed for existing instances so we don't end up 76 offenses
      right away, but for new code one should _only_ use this if they _have_
      to remove non database data. Even then it's usually better to do this in
      a service class as this gives you more control over how to remove the
      data (e.g. in bulk).
    • Add many foreign keys to the projects table · c63e3221
      Yorick Peterse authored
      This removes the need for relying on Rails' "dependent" option for data
      removal, which is _incredibly_ slow (even when using :delete_all) when
      deleting large amounts of data. This also ensures data consistency is
      enforced on DB level and not on application level (something Rails is
      really bad at).
      
      This commit also includes various migrations to add foreign keys to
      tables that eventually point to "projects" to ensure no rows get
      orphaned upon removing a project.
  6. 05 Jul, 2017 1 commit
  7. 21 Jun, 2017 1 commit
  8. 16 Jun, 2017 2 commits
  9. 02 Jun, 2017 1 commit
  10. 13 May, 2017 1 commit
  11. 12 May, 2017 1 commit
  12. 04 May, 2017 2 commits
  13. 21 Apr, 2017 1 commit
  14. 10 Apr, 2017 2 commits
  15. 06 Apr, 2017 1 commit
  16. 05 Apr, 2017 1 commit
  17. 04 Apr, 2017 1 commit
  18. 21 Mar, 2017 1 commit
  19. 17 Mar, 2017 1 commit
  20. 14 Mar, 2017 2 commits
  21. 23 Feb, 2017 1 commit
  22. 17 Feb, 2017 1 commit
  23. 27 Jan, 2017 3 commits
  24. 03 Jan, 2017 1 commit
  25. 20 Dec, 2016 1 commit
  26. 15 Dec, 2016 1 commit
  27. 02 Dec, 2016 1 commit
  28. 23 Nov, 2016 2 commits
    • Remove event caching code · 5371da34
      Yorick Peterse authored
      Flushing the events cache worked by updating a recent number of rows in
      the "events" table. This has the result that on PostgreSQL a lot of dead
      tuples are produced on a regular basis. This in turn means that
      PostgreSQL will spend considerable amounts of time vacuuming this table.
      This in turn can lead to an increase of database load.
      
      For GitLab.com we measured the impact of not using events caching and
      found no measurable increase in response timings. Meanwhile not flushing
      the events cache lead to the "events" table having no more dead tuples
      as now rows are only inserted into this table.
      
      As a result of this we are hereby removing events caching as it does not
      appear to help and only increases database load.
      
      For more information see the following comment:
      https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6578#note_18864037
    • Drop Project#authorized_for_user? in favor of ProjectTeam#member? · 91633281
      Ahmad Sherif authored
      Closes #23938
  29. 17 Nov, 2016 1 commit
  30. 14 Nov, 2016 1 commit
  31. 09 Nov, 2016 1 commit