> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt

# Parallelize Query Execution Across Segments

The `concurrent` option enables intra-query parallelism. In this mode, MongoDB Search utilizes more resources, but improves each individual query latency. This feature is only available for [dedicated Search Nodes.](https://www.mongodb.com/docs/search/deployment/deployment-options.md#std-label-what-is-search-node)

## `concurrent` Option Limitations

When you run queries with the `concurrent` option, MongoDB Search doesn't guarantee that each query executes concurrently. For example, when too many concurrent queries are queued, MongoDB Search might fallback to single-threaded execution.

## Syntax

`concurrent` has the following syntax:

```json
{
  "$searchMeta"|"$search": {
    "index": "<index name>", // optional, defaults to "default"
    "<operator>": {
      <operator-specifications>
    },
    "concurrent": true | false,
    ...
  }
}
```

## Behavior

The `concurrent` boolean option allows you to request MongoDB Search to parallelize query execution across segments, which often improves the response time. You can set one of the following values for the `concurrent` option:

- `true` - to request MongoDB Search to run the query multi-threaded

- `false` - to run the query single-threaded (default)

MongoDB Search provides you control over this behavior on a per-query basis to enable concurrent execution only for heavy and long-running queries, which minimizes the contention and improves overall query throughput. Concurrent execution is especially efficient on large datasets, as there is a larger amount of segments.

## CPU Usage

MongoDB Search runs a concurrent query on multiple threads, so the query completes faster. But the query consumes more CPU on your [Search Nodes](https://www.mongodb.com/docs/search/deployment/deployment-options.md#std-label-what-is-search-node) while it runs. Enabling the `concurrent` option for high-volume or short-running queries can saturate the CPU on your Search Nodes and reduce overall query throughput. To limit the impact on CPU, enable the `concurrent` option only for the heavy and long-running queries that benefit from lower latency.

To measure the CPU cost of an individual query, run the query with [explain](https://www.mongodb.com/docs/search/query/explain.md#std-label-explain-ref) and review the `userTimeMs`, `systemTimeMs`, and `maxReportingThreads` fields in the [resourceUsage](https://www.mongodb.com/docs/search/query/explain.md#std-label-explain-search-resource-usage) document.

To monitor CPU usage across your deployment, view the Atlas [cluster metrics](https://www.mongodb.com/docs/atlas/monitor-cluster-metrics.md#std-label-monitor-cluster-metrics) and the [Review MongoDB Search Metrics](https://www.mongodb.com/docs/atlas/review-atlas-search-metrics.md#std-label-review-atlas-search-metrics). Atlas can also trigger [MongoDB Search alerts](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/atlas-search-alerts.md#std-label-atlas-search-alerts) that measure the amount of CPU that MongoDB Search processes use. If CPU usage approaches the limits of acceptable performance, scale your Search Nodes vertically or horizontally. To learn more, see [Tips for Sizing and Scaling Search Nodes.](https://www.mongodb.com/docs/search/deployment/deployment-options.md#std-label-fts-search-node-sizing-tips)

## Example

Consider the following query against the [sample\_mflix.movies](https://www.mongodb.com/docs/manual/sample-data/sample-mflix.md#std-label-sample-mflix) collection in the sample data. The query indicates a concurrent search for movies that contain the term `new york` in the `title`.

```json
db.movies.aggregate([
  {
    "$search": {
      "text": {
        "path": "title",
        "query": "new york"
      },
      "concurrent": true
    }
  }
])
```