Commit graph

5 commits

Author SHA1 Message Date
Francisco Lopez
194f7bca9a Comments from code review applied. Also switched forked_from_project and ForkedProjectLinks to ForkNetworkMember 2017-12-01 18:32:12 +01:00
Francisco Lopez
a2babf32fe More preloading improvement and added batch count services 2017-12-01 18:32:12 +01:00
Yorick Peterse
3e561736b2
Cache the number of user SSH keys
By caching the number of personal SSH keys we reduce the number of
queries necessary on pages such as ProjectsController#show (which can
end up querying this data multiple times).

The cache is refreshed/flushed whenever an SSH key is added, removed, or
when a user is removed.
2017-11-16 14:59:38 +01:00
Yorick Peterse
57b96eb6db
Fix refreshing of issues/MR count caches
This ensures the open issues/MR count caches are refreshed properly when
creating new issues or MRs. This MR also includes a change to the cache
keys to ensure all caches are rebuilt on the fly.

This particular problem was not caught in the test suite due to a null
cache being used, resulting in all calls that would use a cache using
the underlying data directly. In production the code would fail because
a newly saved record returns an empty hash in #changes meaning checks
such as `state_changed? || confidential_changed?` would return false for
new rows, thus never updating the counters.

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/38061
2017-09-19 17:16:45 +02:00
Yorick Peterse
6ec53f5d48
Cache the number of open issues and merge requests
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
2017-08-23 13:42:29 +02:00