Eric Cooper so I can reproduce the test (or something similar).
But is a smaller 'value' better? The unit reported by the test is I presume the wall-clock time for the rebalance to complete?
So I'm just trying to get a feel for what the test really does and the load/operations it places on the cluster. I'm limited to running VMs on my Macbook and found that for some reason the test hung if I tried the default (just seemed to be doing nothing). However the test works with 5 buckets, so I've stuck with that for now.
With 4.5.1 I don't see a pronounced regression, comparing 4.5.1 2801 vs 2802 doing 2 runs of each I got the following values.
*4.5.1-2801 : 3.96, 3.93
*4.5.1-2802 : 3.93, 4.00
Not a strong regression, maybe that 4.00 is a trend towards 2802 being slower.
On 4.7 I see an improvement, and as you observed only moxi went away?
- 4.7-837 : 3.97, 3.93
- 4.7-838 : 3.01, 3.01
That is 4.7-838 is faster? However you've seen that it is slower? If this is faster, my hypothesis is that the removal of moxi may have freed some resources on these "small" systems which are overloaded by the many bucket config.
Overall though, what is this defect tracking? The value change triggered by moxi (smaller is better???) or 4.5.1, as the comments are really leading to two different issues and should perhaps become two different MBs.
So to summarise my questions for now:
- What is the value reported by this test?
- A smaller value better? (larger_is_better = false is set in the test spec)
- What are all the pairs of builds where a change is seen? I.e. 4.7-837 to 4.7-838, 4.5.1-x to 4.5.1-y, is there another pair of 4.7 builds where a regression appears?
Jim, the procedure you use is similar to what you did for
MB-20482, though the command is:python -u perfSanity/scripts/perf_regression_runner_alpha.py -e -v 4.7.0-837 -r 2016-07-14:13:18 -q "testName='reb_in_10_buckets'" -n -e
Please let me know if you need more information on this.