This documentation is generated from the yaml files in the src/phases directory. The phases listed here are limited in scope to the Genny repo.
We parse the keywords, owner, description, and the phase name from each yaml file to generate this documentation. Clicking on the header of each phase will take you to its yaml file in the repo.
If you want to update the documentation please update the phase's respective yaml file, run ./run-genny generate-docs, and commit the changes.
Product Performance
Example phase to illustrate how PhaseConfig composition works.
Server Security
With queryable encryption enabled, this workload runs alternating CRUD and compact phases, where the total number of inserts & updates is increased on every CRUD+Compact cycle in order to grow the ECOC collection to a size that is at least twice its pre-compaction size in the previous cycle. This is meant to test how long compaction takes relative to ECOC size. Parameters: Database: name of encrypted database Collection: name of encrypted collection ClientName: name of encrypted client pool Namespace: namespace of the encrypted collection
Server Security
Phase definitions for encrypted YCSB-like workloads. This defines the YCSBLikeActor that emulates the MongoDB YCSB workloads. Parameters: Database: name of encrypted database Collection: name of encrypted collection ClientName: name of encrypted client pool Threads: number of client threads for the CrudActor Filter: filter document to use for find and update operations UpdateDocument: document used in the $set field of an update operation InsertDocument: document to insert during the load phase 100ReadRepeat: how many iterations of the 100% read phase to run per thread 95Read5UpdateRepeat: how many iterations of the 95/5 phase to run per thread 100UpdateRepeat: how many iterations of the 100% update phase to run per thread 50Read50UpdateRepeat: how many iterations of the 50/50 phase to run per thread
Server Security
Template for encryption-enabled workloads that emulate a YCSB workload. Performs queries on an encrypted field, instead of _id, during the read/update phase. Parameters: Database: name of encrypted database Collection: name of encrypted collection ClientName: name of encrypted client pool FieldValue: value of the nth field (n is 1..8)
Storage Execution
Run basic insert and find and delete workload on a collection clustered by {_id: 1} . Clustered collections are planned to mainly serve operations over the cluster key such as monotonically increasing inserts, range queries and range deletions.
Storage Execution
This Phase has 2 actors, InsertData and IndexCollection. InsertData inserts documents containing all types of indexes, and IndexCollection creates indexes for each of them, one at a time.
Storage Execution
Runs mass deletions over a set of 1KB documents, then mass deletions over a set of larger, 10MB documents. For each size of document: . Populates a collection with documents of size n-bytes, then performs a mass deletion on the collection. . Repopulates a collection with documents of size n-bytes, then performs a mass deletion while performing concurrent writes on another collection. Allows for comparing the performance of the DELETE_STAGE vs the BATCHED_DELETE_STAGE, primarily in terms of deletion throughput, and w:majority latencies of the concurrent writes. Also, allows for comparisons in performance when mass deletions are performed over different sized documents. The mass deletion namespace is test.Collection0 The concurrent writes namespace is test.concurrentWritesColl
RunCommand, Loader, LoggingActor, CrudActor, insert, delete, batch, deleteMany, latency
Storage Execution
Set up 1000 independent sensors which will each have 100 buckets, and each bucket has 100 measurements.
The buckets have the meta field, 'sensorId', with values from 0 to 999, each of which has 100 measurements with timestamps within an hour with 36-second intervals. For example, in a bucket, the measurements look like: {t: 2023-01-01T5:00:00, m: 42, ...}, {t: 2023-01-01T5:00:36, m: 42, ...}, ... {t: 2023-01-01T5:59:24, m: 42, ...}
Storage Execution
Runs a workload that updates a large range of documents. Multiple secondary indexes are present. Update performed with and without a hint.
RunCommand, Loader, LoggingActor, CrudActor, insert, update, latency
Storage Execution
This workload inserts ~1GB of documents, creates various indexes on the data, and then runs the validate command. We created this workload to see the performance benefits of improvements to the validate command, including background validation.
Storage Execution
Configuration for the MultiDeletes workload.
Storage Execution
Configuration for MultiDeletes workload. This configuration introduces secondary indexes.
@mongodb/query
This file defines a template to use in aggregation expression performance tests.
Query Optimization
This workload measures performance of boolean expressions which can be simplified by the Boolean Simplifier. It is designed to track effectiveness of the simplifier.
@mongodb/query
This workload tests the performance of collection scan queries with complex predicates of various shapes (CNF, DNF, and mixed predicates with different levels of nestedness).
@mongodb/query
Defines complex, randomly generated CNF and DNF queries used in 'CollScanComplexPredicate.yml'.
@mongodb/query
This workload tests the performance of collection scan queries against a collection containing documents with a large number of fields.
Loader, CrudActor, QuiesceActor, insert, find
@mongodb/query
This workload runs collscan queries on various data types.
@mongodb/query
This workload tests the performance of collection scan queries which include conjunctions where the order of predicates matters due to selectivity of the predicates. In actors' names, a 'good' case means that the ordering of predicates defined by actual selectivities matches the ordering defined by heuristic selectivity estimation. Similarly, an 'indistinguishable' case means that heuristic CE defines the same selectivity for all predicates in the query. For this workload, the important metrics to look at are OperationThroughput and all latency measurements.
Loader, CrudActor, QuiesceActor, insert, find
@mongodb/query
This workload runs collscan queries with a large projection on around 20 fields.
@mongodb/query
This workload tests the performance of collection scan queries with complex predicates that can be simplified by the optimizer.
@mongodb/query
This workload stresses the query execution engine by running queries with complex logical expressions that never match a document in the collection. Each workload name consists of several parts: '{SyntaxType}{PredicateType}'. 'SyntaxType' can be:
- 'AggregationExpression' means expressions which can be used inside $expr
- 'MatchExpression' means operators of the find command match predicate language 'PredicateType' can be:
- 'DeepPredicate' means query with deeply nested expressions
- 'WidePredicate' means query where operators have a large number of arguments
- 'SingletonPredicateWithDeepFieldpaths' means query with a single equality predicate where nested fieldpaths like '$a.b.c' are used
- 'WidePredicateWithDeepFieldpaths' means a wide query where nested fieldpaths like '$a.b.c' are used
- 'MixedPredicate' means query which combines wide and deep types
- 'TargetPath' and 'MissingPath' mean query which targets a path present only in some documents
- 'MissingPathSuffix' means query is searching a path whose suffix cannot be found in the document
Loader, CrudActor, QuiesceActor, insert, find
Query Execution
This file defines a parameterized configuration 'GetBsonDate' to work around the issue of ISODate.
TODO PERF-3132 Use the date generator instead of this workaround.
@mongodb/query
This file defines templates to use in workloads exercising aggregate stages on computed time fields.
@mongodb/query
Defines common configurations for IDHack query workloads.
Query Execution
Defines common configurations for 'LookupSBEPushdown' and 'LookupSBEPushdownMisc' workloads.
@mongodb/query
This workload tests a set of filters in the match language. The actors below offer basic performance coverage for said filters.
Loader, CrudActor, QuiesceActor, insert, find
@mongodb/query
This file defines templates to use in multiplanner performance tests.
@mongodb/query
This workload stresses the query execution engine by running queries over a set of paths which share a common prefix. Crucially, these queries never match a document in the collection.
Loader, CrudActor, QuiesceActor, insert, find
@mongodb/query
This phase template constructs an aggregation pipeline that multiplies together the provided arguments.
@mongodb/query
These are the phases used to measure performance of the last-point-in-time query optimization on timeseries collections.
@mongodb/query
These are the phases used to measure performance of the bounded sorter for timeseries collections.
@mongodb/query
Defines common configurations for workloads that operate on views.
Replication
Common definitions to support the workloads in replication/startup.
Performance Infrastructure
Common definitions to support the workloads in scale/LargeScale. See LargeScaleSerial.yml for a general overview of what the large-scale workloads are testing.
Note that there aren't any performance targets defined - these were moved to an out-of-band tracking system that automatically spots regressions across all recorded measurements.
Storage Execution
This is the set of shared phases for the Large Scale Workload Automation project.
Since the LSWA workloads contain common phases, they've been separated in this phase file and can
be included in each workload as needed via the ExternalPhaseConfig functionality.
Product Performance
Phase defintions for the MixedWorkloadsGenny, which is a port of the mixed_workloads in the workloads repo. https://github.com/10gen/workloads/blob/master/workloads/mix.js. It runs 4 sets of operations, each with dedicated actors/threads. The 4 operations are insertOne, findOne, updateOne, and deleteOne. Since each type of operation runs in a dedicated thread it enables interesting behavior, such as reads getting faster because of a write regression, or reads being starved by writes. The origin of the test was as a reproduction for BF-2385 in which reads were starved out by writes.
scale, insertOne, insert, findOne, find, updateOne, update, deleteOne, delete
Cluster Scalability
Template for setting a cluster parameter.
Cluster Scalability
Template for sharding a collection.
Cluster Scalability
This workload template does the following (with PauseMigrationsDuringMultiUpdates disabled):
- Create an unsharded collection.
- Insert 50k documents of around 20kB each using the monotonic loader.
- Run updateMany as many times as possible in two 5 minute phases, where updateMany will update all of the 50k documents per command in the first phase and only a single document per command in the second phase.
Two parameters are accepted to alter the behavior of this workload:
- ShardCollectionPhases: Valid values are [] and [1]. If set to [] (default), the collection remains unsharded. If set to [1], the collection will be sharded with a hashed shard key on _id.
- PauseMigrationsPhases: Valid values are [] and [1]. If set to [] (default), PauseMigrationsDuringMultiUpdates will be disabled. If set to [1], PauseMigrationsDuringMultiUpdates will be enabled.
The intent of this workload is to measure the throughput of updateMany, so the OperationThroughput and OperationsTotal metrics for DocumentUpdater.UpdateAll and DocumentUpdater.UpdateOne should be used to evaluate performance when updating all documents per command and a single document per command respectively.
AdminCommand, MonotonicSingleLoader, CrudActor, updateMany, sharding
@mongodb/product-query
Run TPC-H query 1 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 10 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 11 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 12 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 13 gainst the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 14 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 15 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 16 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 17 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 18 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 19 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 2 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 20 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 21 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 22 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 3 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 4 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 5 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 6 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 7 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 8 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 9 against the denormalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 1 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 10 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 11 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 12 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 13 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 14 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 15 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 16 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 17 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 18 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 19 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 2 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema.
@mongodb/product-query
Run TPC-H query 20 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 21 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 22 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 3 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 4 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 5 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 6 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 7 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 8 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.
@mongodb/product-query
Run TPC-H query 9 (see http://tpc.org/tpc_documents_current_versions/pdf/tpc-h_v3.0.0.pdf) against the normalized schema. Using an 'executionStats' explain causes each command to run its execution plan until no documents remain, which ensures that the query executes in its entirety.