delta/gitlab/gitlab-ce.git/lib/tasks/cache.rake, branch kubernetes-http-response-code

Allow `rake cache:clear` clearing pipeline status cache

2018-04-10T12:57:00+00:00

* Use the correct key prefix
* Clear old cache keys

TODO:

At some point we could remove clearing old cache keys.

Support multiple Redis instances based on queue type

2017-07-11T03:35:47+00:00

Remove the ClearDatabaseCacheWorker

2017-04-21T10:52:28+00:00

Don’t exclude some file in lib from rubocop

2017-02-23T15:32:42+00:00

Stop clearing the database cache on rake cache:clear

2016-10-22T11:42:19+00:00

Add markdown cache columns to the database, but don't use them yet

2016-10-07T01:54:25+00:00

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.

Put CACHE_NAMESPACE in the Gitlab::Redis module

2016-04-07T13:42:07+00:00

Add Gitlab::Redis connection pool

2016-04-04T15:00:09+00:00

Parse config/resque.yml in one place only

2016-03-09T14:16:46+00:00

Batch size >1000 does not pay off

2016-02-25T12:50:08+00:00

We did a small experiment to see how a full scan of the Redis keys on
gitlab.com speeds up as we increase the batch size. The values on the
right are time in seconds for a full scan (no delete operations).

count: 10);      284.500529021
count: 100);      86.21216934
count: 1_000);    60.931676195
count: 10_000);   60.96355610
count: 100_000);  62.378172541

It looks like 1,000 is a good number.