The so called "Top Chunk Optimisation" in Sharding operates by checking whether writes are happening to the highest (or lowest) chunk of a collection and pre-splitting and possibly moving that chunk to a different shard. This is done in order to ensure that the "top chunks" are moved while empty (or as small as possible), rather than when they are full of data.

Given that it only looks at the extreme chunks of the collection, the top chunk optimisation appears to only be useful for the cases where the collection is bulk-loaded, on a single thread, using data sorted on the shard key.

Without this pattern, the top chunk optimisation is largely unused and in certain cases causes issues, because it would block the threads performing inserts to the extreme chunks. The blocking issue was mostly fixed in 4.2 by moving the auto-splitter to the shard servers and making it asynchronous, but in older versions it still persists.

This ticket is to design and introduce metrics, which would validate the usefulness of the TCO. If it is determined that it is not useful, we will remove it.