When we repeatedly create and drop large collections, the extent freelist gets very long and the server starts to take a long time to find a suitable freed extent to reuse while the database being write-locked. It can take from 10 sec to several minutes depending on the length of freelist. This is related to SERVER-3022 if I understand it correctly.

warning: newExtent 16365 scanned
warning: slow scan in allocFromFreeList (in write lock)

There would be three approaches to mitigate this problem:

1. Let users specify the size of initial extent both for collection data and indices to possibly reduce the number of extents to be allocated. This used to be partially achieved by passing size parameter on db.createCollection but it's no longer possible since 2.6.0 (see SERVER-13144). If a collection is supposed to grow to a large size (say 100 MiB), it makes no sense to start from the minimum extent, namely 4096 bytes long.
2. Merge two freed extents if they are adjacent to each other. This could reduce the length of freelist.
3. Have a cache of extent freelist on heap for faster searching. It's so slow to do random access on mmapped pages due to repeated page faults and disk seek/reads.