diff options
author | Rémy Coutable <remy@rymai.me> | 2016-08-08 15:35:50 +0000 |
---|---|---|
committer | Rémy Coutable <remy@rymai.me> | 2016-08-08 15:35:50 +0000 |
commit | fd3a2cf76318a84dc6d3bab9bd9a767c5112106d (patch) | |
tree | 9d43fa6355747241fcfcc9309337c47be3337ae8 /lib/gitlab/import_export/members_mapper.rb | |
parent | 46e9d8f08db13659fac02e61ef6ce8917bf6a0ac (diff) | |
parent | 77c8520e2ecd70520757aed0fbdf434643b60234 (diff) | |
download | gitlab-ce-fd3a2cf76318a84dc6d3bab9bd9a767c5112106d.tar.gz |
Merge branch 'faster-cache-keys' into 'master'
Optimize "cache_key" using a concern
## What does this MR do?
This MR adds a concern (used by Issue and Note) that provides an optimized version of Rails' `cache_key` method. See 77c8520e2ecd70520757aed0fbdf434643b60234 for more details.
## Are there points in the code the reviewer needs to double check?
No, though a spell check would be appreciated.
## Why was this MR needed?
When loading a lot of data from Redis (e.g. an issue with lots of notes) quite a large amount of time is spent in generating cache keys. This is due to multiple reasons such as:
* Rails trying to figure out if it should use `updated_at` or `updated_on` using somewhat inefficient code
* Rails relying on pluralization logic to figure out how to generate a cache namespace using a model name
* Rails calling a whole bunch of methods in general in the process of generating cache keys
In short, Rails is trying to cater to every possible use case, at the cost of performance.
## What are the relevant issue numbers?
https://gitlab.com/gitlab-org/gitlab-ce/issues/13651 is not directly related but I ran into this `cache_key` problem when looking into said issue.
See merge request !5715
Diffstat (limited to 'lib/gitlab/import_export/members_mapper.rb')
0 files changed, 0 insertions, 0 deletions