A workload designed to stress the cursor manager.
Test
The purpose of this test is to expose scalability issues in the cursor manager. As part of the "all cursors globally managed" project, in mongodb 4.2 all cursors are owned by a single cursor manager (rather than by a per-collection cursor manager, as in 4.0 and earlier). Putting all cursors into a single data structure created an obvious opportunity for a bottleneck on finds, getMores and killCursors.
The test inserts some data into several collections, and then has many threads run find and getMore operations with a small batch size, in an attempt to create contention in the cursor manager.
Setup
Supports standalone
Owning-team
mongodb/product-query
- Source:
Members
(inner) nCollections
The number of collections to create and run queries against
- Source:
(inner) numDocs
Number of documents per collection.
- Source:
(inner) test_duration_secs
Duration of the test.
- Source:
(inner) thread_levels
The number of threads to run in parallel. TODO PERF-1809: Determine thread levels for this workload.
- Source:
Methods
(inner) createQueryingThreads()
Create some CursorIteratingThreads, evenly assigning them to the given collections. Initially the threads are in a "blocked" state, and, although they are running, do not do anything.
- Source:
(inner) CursorIteratingThread()
Represents a thread which takes a collection name, and repeatedly opens and iterates a cursor on the collection with a small batch size.
- Source:
(inner) insertDocs()
For each collection in the 'colls' array, insert 'numDocs' documents, each with just two integer fields, e.g. {x: 1, y: 3}.
- Source:
(inner) joinThreads()
Inform each thread to stop, and return when they've all completed. Returns the total number of documents that were returned from the server across all threads.
- Source:
(inner) unblockQueryingThreads()
Given a list of threads, unblock them all.
- Source: