6 ms·
Author here: Note that the 4 hours per bisection is the time to ramp the server up and down and re-image it. It does not count the time to actually do the bi
by drewg123 2y ago
Author here:
Note that the 4 hours per bisection is the time to ramp the server up and down and re-image it. It does not count the time to actually do the bisection step. That's because in our case of following head, the merging & conflicts were trivial for each step of the 3 week bisection. Eg, the bisections we're doing are far simpler than the bisections we'd be doing if we didn't track the main branch, and had a far larger patchset that had to be re-merged at each bisection point. I'm cringing just imagining the conflicts.
- crote 2y agoDoes "the server" imply you're only using a single server for this? I would have expected that at Netflix's scale it wouldn't be too difficult to do the whole bisect-and-test on a couple dozen servers in parallel.
- generalizations 2y agoWouldn't each bisect depend on the ones before it? So you can't ramp up the next test before you finish the prior.
- crote 2y agoOh right, that's obviously not going to work unless you're willing to waste a huge amount of resources on speculative execution. The fact that the selection of the next bisect depends on the result of the current one completely slipped my mind!
- toast0 2y agoYou could speculate in both directions, and test three revisions in parallel... However, if there's a lot of manual merging to do, you might not want to do the extra merge that's involved there. You might also get nerd sniped into figuring out if there's a better pattern if you're going to test multiple revisions in parallel.