# Long CPU intensive activities in single threaded languages (Python or Javascript) **URL:** \ **Category:** Community Support\ **Tags:** python-sdk, performance, configuration\ **Created:** [May 1, 2024, 9:02am UTC](https://community.temporal.io/t/long-cpu-intensive-activities-in-single-threaded-languages-python-or-javascript/11961 "2024-05-01T09:02:26Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Amitai\_Levy](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/amitai_levy/32/5137_2.png) [@Amitai\_Levy](https://community.temporal.io/u/Amitai_Levy)\ **Post date:** [May 1, 2024, 9:02am UTC](https://community.temporal.io/t/long-cpu-intensive-activities-in-single-threaded-languages-python-or-javascript/11961/1 "2024-05-01T09:02:26Z")
### Background: In our workflow we have: 1. Short running activities 2. Long running **CPU intensive** activities 3. Queries, Signals, etc. In addition, we are using the Python SDK. ### What I would expect: A worker which is busy processing a long running activity will not pick up any other activities (or queries or signals) until it has finished processing it. ### What is actually happening: The moment the intensive activity is picked up, we are noticing many other short running activities or queries are timing out. I assume they are being picked up by the busy worker, who’s process is busy with the long running activity. ### What is the recommended configuration / solution? Is there any configuration that should be set specifically for single threaded languages such as Python or Javascript? I assume defining workers for cpu intensive activities separately from the workers for short running activities is one solution, but is there a way to avoid this operational overhead? Thanks for the help. ---
**Author:** ![Chad\_Retz](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/chad_retz/32/1396_2.png) [@Chad\_Retz](https://community.temporal.io/u/Chad_Retz)\ **Post date:** [May 1, 2024, 11:51am UTC](https://community.temporal.io/t/long-cpu-intensive-activities-in-single-threaded-languages-python-or-javascript/11961/2 "2024-05-01T11:51:23Z")
You can use the `max_concurrent_activities` setting when creating a worker to limit the number of activities that worker can run at a time. It is defaulted to 100. It is common to set it to a low number (or even `1`) to limit resource-intensive activities. ---
**Author:** ![Amitai\_Levy](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/amitai_levy/32/5137_2.png) [@Amitai\_Levy](https://community.temporal.io/u/Amitai_Levy)\ **Post date:** [May 1, 2024, 12:39pm UTC](https://community.temporal.io/t/long-cpu-intensive-activities-in-single-threaded-languages-python-or-javascript/11961/3 "2024-05-01T12:39:04Z")
Thanks for the quick reply. Would this setting limit just the concurrent activities? Or would it also make sure not to run any queries, signals or workflow tasks on the worker while it is running an activity? ---
**Author:** ![Chad\_Retz](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/chad_retz/32/1396_2.png) [@Chad\_Retz](https://community.temporal.io/u/Chad_Retz)\ **Post date:** [May 1, 2024, 12:50pm UTC](https://community.temporal.io/t/long-cpu-intensive-activities-in-single-threaded-languages-python-or-javascript/11961/4 "2024-05-01T12:50:46Z")
Just concurrent activities. But you can make activity and/or workflow only workers. If a worker only has activities set on it and no workflows, it never polls workflow work. Similarly if a worker only has workflows set on it and no activities (or does have activities for local activity use but `no_remote_activities=True` is set), then it never polls for activity work. So you can create activity-only and workflow-only workers on a task queue in completely separate areas/processes. ---
**Author:** ![Amitai\_Levy](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/amitai_levy/32/5137_2.png) [@Amitai\_Levy](https://community.temporal.io/u/Amitai_Levy)\ **Post date:** [May 1, 2024, 12:55pm UTC](https://community.temporal.io/t/long-cpu-intensive-activities-in-single-threaded-languages-python-or-javascript/11961/5 "2024-05-01T12:55:22Z")
Ok, and I understand this is the common practice? (If so would it make sense for a feature request to limit all types of concurrent tasks on a worker, not just activities? Would be especially useful for single threaded languages to prevent these issues) And one more clarification - query tasks are considered “Workflow work”? ---
**Author:** ![Chad\_Retz](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/chad_retz/32/1396_2.png) [@Chad\_Retz](https://community.temporal.io/u/Chad_Retz)\ **Post date:** [May 1, 2024, 3:32pm UTC](https://community.temporal.io/t/long-cpu-intensive-activities-in-single-threaded-languages-python-or-javascript/11961/6 "2024-05-01T15:32:36Z")
> [@Amitai\_Levy](#): > > Ok, and I understand this is the common practice? Yes, especially for Python where AI companies want to run activities on limited GPU resources. So they start `max_concurrent_activities=1` activity-only workers on each GPU-based resource and use Temporal to distribute the work. > [@Amitai\_Levy](#): > > (If so would it make sense for a feature request to limit all types of concurrent tasks on a worker, not just activities? Would be especially useful for single threaded languages to prevent these issues) No, because splitting into two workers is basically the same thing. Workers are just activity workers and workflow workers, and there is not very much overlap (local activities notwithstanding). They are just combined for user simplicity but can be split just as easily. > [@Amitai\_Levy](#): > > And one more clarification - query tasks are considered “Workflow work”? Yes, workflow work is anything applying to the workflow from the server. While a query may not technically make a “workflow task” in the event history, it is commonly still referred to as a task to accomplish (and so is governed by `max_concurrent_workflow_tasks`). Granted workflow tasks should take just milliseconds to complete (local activities notwithstanding), so there is not usually a need to limit them to low concurrency. However, they do use memory when cached and so the cache size may be worth tuning.