|
We don't have any tests that exercise capped collection truncation, but this comment provides an explanation for when we expect it to be exercised:
// For a capped collection, the number of documents that can be removed directly, rather than via a
|
// truncate. The value has been determined somewhat by experimentation, but there's no clear win
|
// for all situations. Setting it to a lower number makes individual remove calls happen, rather
|
// than truncate, only when small numbers of documents are inserted at a time. Making it larger
|
// makes larger chunks of documents inserted at time follow the remove path in preference to the
|
// truncate path. Using direct removes is more likely to be a benefit when inserts are spread over
|
// many capped collections, since avoiding a truncate avoids having to get a second cursor, which
|
// may not be already cached in the current session. The benefit becomes less pronounced if the
|
// capped collections are more actively used, or are used in small number of sessions, as multiple
|
// cursors will be available in the needed session caches.
|
static int kCappedDocumentRemoveLimit = 3;
|
Despite losing out on the truncation benefits, we believe that explicitly deleting documents will provide a smoother capped collection experience overall. Primaries and secondaries will always perform the same operations, and primaries and secondaries will continue to serialize capped operations.
|