langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-08-27 03:01:54 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Severe Performance Issues After Upgrade to Version 1.2.0 #13279

New Issue
Closed
opened 2026-02-21 19:11:24 -05:00 by yindo · 3 comments
yindo commented 2026-02-21 19:11:24 -05:00
Owner
Copy Link
Copy Source

Originally created by @KomanLiang on GitHub (Apr 23, 2025).

Self Checks

  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • 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.

Dify version

1.2.0

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

We've encountered severe performance issues after upgrading from version 0.15.0 to 1.2.0. The API pods are frequently restarting, with all 30 database connections constantly maxed out. The CPU load of the pluginDaemon consistently remains around 1100m. The logs from pluginDaemon show that some request takes more than 6 minutes to process.(BTW we do not use workflow)

Image Image

We've deployed the API on the 'dify-api' node with 10 pods (0.5 core, 1GB memory) and 14 pluginDaemons (2 cores, 2GB memory). These resource allocations are already quite substantial. Our website traffic is approximately 100-300 concurrent users, with a daily average of 20,000 unique visitors. Despite these resources, we're still experiencing frequent performance bottlenecks.

Image

✔️ Expected Behavior

We expect the system to run smoothly without significant, widespread slowdowns.

❌ Actual Behavior

No response

Originally created by @KomanLiang on GitHub (Apr 23, 2025). ### Self Checks - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:) - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.2.0 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce We've encountered severe performance issues after upgrading from version 0.15.0 to 1.2.0. The API pods are frequently restarting, with all 30 database connections constantly maxed out. The CPU load of the pluginDaemon consistently remains around 1100m. The logs from pluginDaemon show that some request takes more than 6 minutes to process.(BTW we do not use workflow) <img width="1184" alt="Image" src="https://github.com/user-attachments/assets/67aeb39b-1580-4169-80f9-8a9ae31220b5" /> <img width="640" alt="Image" src="https://github.com/user-attachments/assets/8e294277-cce0-46b4-ac68-d5ab70463d4b" /> We've deployed the API on the 'dify-api' node with 10 pods (0.5 core, 1GB memory) and 14 pluginDaemons (2 cores, 2GB memory). These resource allocations are already quite substantial. Our website traffic is approximately 100-300 concurrent users, with a daily average of 20,000 unique visitors. Despite these resources, we're still experiencing frequent performance bottlenecks. <img width="771" alt="Image" src="https://github.com/user-attachments/assets/b8ea9516-3523-40d2-8a77-1ecd19eb65ac" /> ### ✔️ Expected Behavior We expect the system to run smoothly without significant, widespread slowdowns. ### ❌ Actual Behavior _No response_
yindo added the 🐞 bug label 2026-02-21 19:11:24 -05:00
yindo closed this issue 2026-02-21 19:11:24 -05:00
yindo commented 2026-02-21 19:11:25 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Apr 23, 2025):

Hello @KomanLiang! 👋 I'm Dosu, a friendly bot here to assist you with bugs, questions, and more while you wait for a human maintainer. Let's tackle this together!

Severe performance issues after upgrading to Dify version 1.2.0, such as frequent API pod restarts and high CPU load on the pluginDaemon, could be due to environment variable parsing issues and additional processing overhead in the newer plugin daemon local runtime. Here are some steps you can take to address these issues:

  1. Environment Variables: Ensure that the following settings are added to your .env file to prevent incorrect conversions:

    PLUGIN_S3_USE_AWS_MANAGED_IAM=false
PLUGIN_S3_USE_PATH_STYLE=false

  2. Docker Compose Configuration: Update your docker-compose.yaml file with default values for the plugin daemon:

    plugin_daemon:
  environment:
    S3_USE_AWS_MANAGED_IAM: ${PLUGIN_S3_USE_AWS_MANAGED_IAM:-false}
    S3_USE_PATH_STYLE: ${PLUGIN_S3_USE_PATH_STYLE:-false}

  3. Restart the Application: Use the following commands to restart the application:

    docker compose down
docker rmi $(docker images -q 'dify-*')
docker compose up -d

Additionally, ensure that your docker-compose.yaml file includes the correct configurations for the plugin daemon, such as PLUGIN_PYTHON_ENV_INIT_TIMEOUT and PLUGIN_MAX_EXECUTION_TIMEOUT, to manage resource usage effectively. These steps should help mitigate the performance issues you're experiencing [1][2].

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

@dosubot[bot] commented on GitHub (Apr 23, 2025): <!-- Greeting --> Hello @KomanLiang! 👋 I'm [Dosu](https://dosu.dev), a friendly bot here to assist you with bugs, questions, and more while you wait for a human maintainer. Let's tackle this together! <!-- Answer --> Severe performance issues after upgrading to Dify version 1.2.0, such as frequent API pod restarts and high CPU load on the pluginDaemon, could be due to environment variable parsing issues and additional processing overhead in the newer plugin daemon local runtime. Here are some steps you can take to address these issues: 1. **Environment Variables**: Ensure that the following settings are added to your `.env` file to prevent incorrect conversions: ```plaintext PLUGIN_S3_USE_AWS_MANAGED_IAM=false PLUGIN_S3_USE_PATH_STYLE=false ``` 2. **Docker Compose Configuration**: Update your `docker-compose.yaml` file with default values for the plugin daemon: ```yaml plugin_daemon: environment: S3_USE_AWS_MANAGED_IAM: ${PLUGIN_S3_USE_AWS_MANAGED_IAM:-false} S3_USE_PATH_STYLE: ${PLUGIN_S3_USE_PATH_STYLE:-false} ``` 3. **Restart the Application**: Use the following commands to restart the application: ```bash docker compose down docker rmi $(docker images -q 'dify-*') docker compose up -d ``` Additionally, ensure that your `docker-compose.yaml` file includes the correct configurations for the plugin daemon, such as `PLUGIN_PYTHON_ENV_INIT_TIMEOUT` and `PLUGIN_MAX_EXECUTION_TIMEOUT`, to manage resource usage effectively. These steps should help mitigate the performance issues you're experiencing <sup>[[1]](https://github.com/langgenius/dify/issues/18415)</sup><sup>[[2]](https://github.com/langgenius/dify/issues/17799)</sup>. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/26509e6c-c19f-46d5-8158-615fef7a6090?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/26509e6c-c19f-46d5-8158-615fef7a6090?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/26509e6c-c19f-46d5-8158-615fef7a6090?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/26509e6c-c19f-46d5-8158-615fef7a6090?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/26509e6c-c19f-46d5-8158-615fef7a6090?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/26509e6c-c19f-46d5-8158-615fef7a6090?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/26509e6c-c19f-46d5-8158-615fef7a6090?feedback_type=other)</sup>
yindo commented 2026-02-21 19:11:25 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Apr 23, 2025):

Please try 1.3.0, we have several fixes regarding performance issues not only in dify repo, but also the plugin_daemon.

@crazywoola commented on GitHub (Apr 23, 2025): Please try 1.3.0, we have several fixes regarding performance issues not only in dify repo, but also the plugin_daemon.
yindo commented 2026-02-21 19:11:25 -05:00
Author
Owner
Copy Link
Copy Source

@KomanLiang commented on GitHub (Apr 24, 2025):

after i upgrade to 1.3.0 ,this problem still exist .

Image Image
@KomanLiang commented on GitHub (Apr 24, 2025): after i upgrade to 1.3.0 ,this problem still exist . <img width="1358" alt="Image" src="https://github.com/user-attachments/assets/63cb1e03-ce45-4936-bb12-fd53fc5121e8" /> <img width="265" alt="Image" src="https://github.com/user-attachments/assets/a666d0f0-44df-439e-a329-238f53461b11" />
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#13279
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?