Whether the dify Community Edition executes concurrent workflow calls through api?

[skylineneon]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

Content

We found that concurrency was limited while using the api to call the workflow, However, changing the SERVER_WORKER_AMOUNT, SQLALCHEMY_POOL_SIZE, SERVER_WORKER_CONNECTIONS, and APP_MAX_ACTIVE_REQUESTS parameters does not improve. How can I improve concurrency in community edition?

[dosubot[bot]]

Yes, the Dify Community Edition does support concurrent workflow calls through the API, but its concurrency is limited by several factors. The main controls are SERVER_WORKER_AMOUNT (number of Gunicorn worker processes), SERVER_WORKER_CONNECTIONS (connections per worker), SQLALCHEMY_POOL_SIZE (DB connections), and APP_MAX_ACTIVE_REQUESTS (per-app concurrent requests). However, even after tuning these, you may still see limited concurrency because the Community Edition is designed with modest performance in mind—higher throughput and faster response times are only available in the enterprise edition, and slow response is expected in the community version details.

If you have already increased these parameters and still see bottlenecks, you are likely hitting the built-in performance ceiling of the Community Edition. There are no hidden dynamic limits, but all these caps must be tuned together to avoid resource contention reference. For higher concurrency, the only supported path is to consider the enterprise edition.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[skylineneon]

I want to know the maximum concurrency limit. At present, it is a parallel request, but it is found that it is still executed serially

[dosubot[bot]]

There is no hardcoded maximum concurrency limit specific to the Dify Community Edition. Instead, concurrency is controlled by several configurable parameters: SERVER_WORKER_AMOUNT (default 1), SERVER_WORKER_CONNECTIONS (default 10), SQLALCHEMY_POOL_SIZE (default 30), and APP_MAX_ACTIVE_REQUESTS (default 0, meaning unlimited) reference. Thread pools for workflow execution also have defaults, like MAX_SUBMIT_COUNT (100) and a typical thread pool size of 10.

If your parallel requests are still running serially, it's likely due to workflow or node configuration. For example, the IterationNode runs serially by default unless you explicitly set is_parallel to true in your workflow design. Also, thread pool sizes and parallel depth limits (like WORKFLOW_PARALLEL_DEPTH_LIMIT, default 3) can restrict actual parallelism even if your API calls are concurrent.

If you want higher concurrency, check both your environment variables and your workflow/node settings to ensure parallel execution is enabled and not limited by defaults or thread pool caps. There are no edition-specific hard limits—just conservative defaults that you can adjust reference.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[skylineneon]

Thank you for your answer