diff options
| author | Jacob Vosmaer <contact@jacobvosmaer.nl> | 2016-02-25 15:50:08 +0300 |
|---|---|---|
| committer | Jacob Vosmaer <contact@jacobvosmaer.nl> | 2016-02-25 15:50:08 +0300 |
| commit | a310901280161985ba1680e7923eb917f8deec35 (patch) | |
| tree | 701a41283697416ffee1686c52378851a0ba9339 /lib/tasks | |
| parent | 856153d71299de7ad2c406130151deabfabc3f3f (diff) | |
Batch size >1000 does not pay off
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.
Diffstat (limited to 'lib/tasks')
| -rw-r--r-- | lib/tasks/cache.rake | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/lib/tasks/cache.rake b/lib/tasks/cache.rake index 9e2fb429d57..f221afcf73a 100644 --- a/lib/tasks/cache.rake +++ b/lib/tasks/cache.rake @@ -1,5 +1,5 @@ namespace :cache do - CLEAR_BATCH_SIZE = 1000 # The more the faster, but having too many can crash Ruby + CLEAR_BATCH_SIZE = 1000 # There seems to be no speedup when pushing beyond 1,000 REDIS_SCAN_START_STOP = '0' # Magic value, see http://redis.io/commands/scan desc "GitLab | Clear redis cache" |