Initial and Incremental build regression in 4 GSI Index Test with 128 byte keysize bloom filter tests

We are seeing a regression in both initial and incremental build times for the tests 

Initial index (min), 1 bucket x 100M, 4 2i Indexes, 100K KV ops/sec, 128 byte keysize, Update/Create Workload, PLASMA With Bloom filter

Initial index (min), 1 bucket x 100M, 7 2i Indexes, 100K KV ops/sec, 128 byte keysize, Update Create Workload, PLASMA With Bloom filter

Initial Index values

http://perf.jenkins.couchbase.com/job/hemera/1633/ - 4668 - 49.7mins

http://perf.jenkins.couchbase.com/job/hemera/1634/ - 4701  - 60.5mins

http://perf.jenkins.couchbase.com/job/hemera/1631/ - 4735 - 71.9mins

http://perf.jenkins.couchbase.com/job/hemera/1626/ - 5017 - 69.5mins

Stats comparison : http://cbmonitor.sc.couchbase.com/reports/html/?snapshot=hemera_700-4668_build_secondaryindex_caac&snapshot=hemera_700-4701_build_secondaryindex_9ee9  - 4668 vs 4701

Single index DGM tests for initial and incremental have not regressed

Single index 1024 byte keysize initial and incremental has not regressed in this time

100 Index bucket level test (all 100 index on default collection) has not regressed

The corresponding test with bloom filter disabled has also regressed so it probably does not have anything to with bloom filter setting.

backstore cachemisses are higher

Mainstore cache misses are higher

timings_storage_set is higher