Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify a few items in the docs #15628

Merged
merged 3 commits into from
Oct 9, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 14 additions & 3 deletions docs/3.0/develop/global-concurrency-limits.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -52,13 +52,13 @@ To implement rate limiting, you can configure "slot decay", which determines how

When you set up a concurrency limit with slot decay:
1. Each time a slot is occupied, it becomes unavailable for other tasks to use.
2. The slot eventually becomes available again over time, based on the slot decay rate (i.e. `slot_decay_per_second`).
2. The slot eventually becomes available again over time, based on the slot decay rate (with `slot_decay_per_second`).
3. This creates a "rate limiting" effect, limiting how often slots can be used.

To configure slot decay, set the `slot_decay_per_second` parameter when creating or updating a concurrency limit. This value determines how quickly slots refresh:

- A higher value (e.g., 5.0) means slots refresh quickly. Tasks can run more frequently, but with short pauses between them.
- A lower value (e.g., 0.1) means slots refresh slowly. Tasks run less frequently, with longer pauses between them.
- A higher value (for example, 5.0) means slots refresh quickly. Tasks can run more frequently, but with short pauses between them.
- A lower value (for example, 0.1) means slots refresh slowly. Tasks run less frequently, with longer pauses between them.

For example:

Expand Down Expand Up @@ -362,3 +362,14 @@ async def main():
if __name__ == "__main__":
asyncio.run(main())
```

## Other ways to limit concurrency

In addition to global concurrency limits, Prefect provides several other ways to limit concurrency for fine-grained control.

Unlike global concurrency limits, which are a more general way to control concurrency for any Python-based operation, the following concurrency limit options are specific to Prefect objects:

- [Work pool flow run concurrency limits](/3.0/deploy/infrastructure-concepts/work-pools#manage-concurrency)
- [Work queue flow run concurrency limits](/3.0/deploy/infrastructure-concepts/work-pools#queue-concurrency-limits)
- [Deployment flow run concurrency limits](/3.0/deploy/index#concurrency-limiting)
- [Task run concurrency limits](/3.0/develop/task-run-limits)
6 changes: 2 additions & 4 deletions docs/3.0/develop/task-run-limits.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -10,11 +10,9 @@ Task run concurrency limits use [task tags](#tags). You can specify an optional
task runs in a `Running` state for tasks with a given tag.

<Tip>
Tag-based task concurrency is different from [Global Concurrency Limits](/3.0/develop/global-concurrency-limits), though they can be used to achieve similar outcomes. Global Concurrency Limits are a more general way to control concurrency for any python-based operation, whereas tag-based concurrency limits are specific to Prefect tasks.
Tag-based task concurrency is different from [Global concurrency limits](/3.0/develop/global-concurrency-limits), though they can be used to achieve similar outcomes. Global concurrency limits are a more general way to control concurrency for any Python-based operation, whereas tag-based concurrency limits are specific to Prefect tasks.
</Tip>



If a task has multiple tags, it will run only if **_all_** tags have available concurrency.

Tags without specified concurrency limits are treated as unlimited. Setting a tag's concurrency limit to 0 causes immediate abortion of any task runs with that tag, rather than delaying them.
Expand All @@ -30,7 +28,7 @@ and instructs the client to try entering a `Running` state again in 30 seconds
### Configure concurrency limits

<Tip>
**Flow run concurrency limits are set at a work pool and/or work queue level**
**Flow run concurrency limits are set at a work pool, work queue, or deployment level**

While task run concurrency limits are configured through tags (as shown below), [flow run concurrency limits](/3.0/develop/global-concurrency-limits) are configured through work pools and/or work queues.
</Tip>
Expand Down
1 change: 1 addition & 0 deletions docs/3.0/develop/task-runners.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -79,6 +79,7 @@ If you don't specify a task runner for a flow and you call a task with `.submit(
Prefect uses the default `ThreadPoolTaskRunner`.
</Tip>

The `max_workers` parameter of the `ThreadPoolTaskRunner` controls the number of threads that the task runner will use to execute tasks concurrently.

## Access results from submitted tasks

Expand Down
Loading