From 54534e725fb13ba84cd873e4ee3534cfa23504d5 Mon Sep 17 00:00:00 2001
From: martinsumner <martin.sumner@adaptip.co.uk>
Date: Mon, 13 Mar 2017 19:53:12 +0000
Subject: [PATCH] Experiment with smaller scan width

When testing with large numbers of 2i terms (and hence more Riak
Metadata), there is a surge in slow response times when there are
multiple concurrent merge events.

This could be veyr short term CPU starvation because of the merge
process.  Perhaps it is delays waiting for the scan to complete -
smaller scanwidth may mena more interleaving and less latency?
---
 src/leveled_sst.erl | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/leveled_sst.erl b/src/leveled_sst.erl
index 76dc9b5..5e4670b 100644
--- a/src/leveled_sst.erl
+++ b/src/leveled_sst.erl
@@ -69,8 +69,7 @@
 -define(COMPRESSION_LEVEL, 1).
 -define(BINARY_SETTINGS, [{compressed, ?COMPRESSION_LEVEL}]).
 % -define(LEVEL_BLOOM_BITS, [{0, 8}, {1, 10}, {2, 8}, {default, 6}]).
--define(MERGE_SCANWIDTH, 16).
--define(INDEX_MARKER_WIDTH, 16).
+-define(MERGE_SCANWIDTH, 4).
 -define(DISCARD_EXT, ".discarded").
 -define(DELETE_TIMEOUT, 10000).
 -define(TREE_TYPE, idxt).