summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJacob Vosmaer <contact@jacobvosmaer.nl>2016-02-25 13:50:08 +0100
committerJacob Vosmaer <contact@jacobvosmaer.nl>2016-02-25 13:50:08 +0100
commita310901280161985ba1680e7923eb917f8deec35 (patch)
tree701a41283697416ffee1686c52378851a0ba9339
parent856153d71299de7ad2c406130151deabfabc3f3f (diff)
downloadgitlab-ce-comment-batch-size.tar.gz
Batch size >1000 does not pay offcomment-batch-size
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.
-rw-r--r--lib/tasks/cache.rake2
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"