The code executor of Dify-1.11.2 has a very slow response when accessing the API interface. #21392

Open
opened 2026-02-21 20:12:20 -05:00 by yindo · 12 comments
Owner

Originally created by @zgz757183190 on GitHub (Dec 31, 2025).

Originally assigned to: @fatelei on GitHub.

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • 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, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交,否则会被关闭 :)
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.11.2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Dify-1.11.2 suffers from significant latency on the initial request to the target port when executing the code below:
response = requests.post(
api_url,
json=payload,
timeout=60
)

Image

Nonetheless, all subsequent requests to the same port exhibit normal latency.

Image

✔️ Expected Behavior

Dify-0.9.2 functions normally, with API requests working properly.

Actual Behavior

No response

Originally created by @zgz757183190 on GitHub (Dec 31, 2025). Originally assigned to: @fatelei on GitHub. ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [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, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交,否则会被关闭 :) - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.11.2 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce Dify-1.11.2 suffers from significant latency on the initial request to the target port when executing the code below: response = requests.post( api_url, json=payload, timeout=60 ) <img width="554" height="294" alt="Image" src="https://github.com/user-attachments/assets/d195fd7f-b7c0-4b3d-83cc-46397ee93089" /> Nonetheless, all subsequent requests to the same port exhibit normal latency. <img width="553" height="284" alt="Image" src="https://github.com/user-attachments/assets/f2b0f4c6-8cdc-4321-aeeb-0cb20676bfc4" /> ### ✔️ Expected Behavior Dify-0.9.2 functions normally, with API requests working properly. ### ❌ Actual Behavior _No response_
yindo added the 🐞 bug label 2026-02-21 20:12:20 -05:00
Author
Owner

@zgz757183190 commented on GitHub (Dec 31, 2025):

Dify-1.11.2 suffers from significant latency on the initial request to the target port when executing the code below:
response = requests.post(
api_url,
json=payload,
timeout=60
)
Image

Nonetheless, all subsequent requests to the same port exhibit normal latency.

Image
@zgz757183190 commented on GitHub (Dec 31, 2025): Dify-1.11.2 suffers from significant latency on the initial request to the target port when executing the code below: response = requests.post( api_url, json=payload, timeout=60 ) <img width="1563" height="828" alt="Image" src="https://github.com/user-attachments/assets/148d951b-3b9d-49a7-81a3-4e6818da1bf3" /> Nonetheless, all subsequent requests to the same port exhibit normal latency. <img width="1536" height="788" alt="Image" src="https://github.com/user-attachments/assets/4c20794d-eeae-4875-bad4-f9cdac8b58c8" />
Author
Owner

@dosubot[bot] commented on GitHub (Dec 31, 2025):

The initial latency you’re seeing in Dify 1.11.2 is due to how the code executor now handles HTTP client pooling. On the first request, Dify creates a new HTTP client and establishes the initial connection to the sandbox service, which can involve TLS/DNS handshakes and backend startup—this is what causes the delay. Subsequent requests reuse the pooled client and established connections, so they’re much faster (source, source).

You can tune these environment variables in your Docker/.env config to optimize pooling and reduce cold start impact:

  • CODE_EXECUTION_POOL_MAX_CONNECTIONS
  • CODE_EXECUTION_POOL_MAX_KEEPALIVE_CONNECTIONS
  • CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY

For overall performance, also review:

  • Celery worker settings (CELERY_WORKER_AMOUNT, CELERY_AUTO_SCALE)
  • Database and Redis pool sizes
  • Server concurrency (SERVER_WORKER_AMOUNT, GRAPH_ENGINE_MAX_WORKERS)
  • Disable SSRF proxy if not needed

If API calls are still slow, try setting "response_mode": "streaming" in your API requests to get incremental results faster (source).

If the issue persists, check for external network bottlenecks (reverse proxy, Docker network) and consider sharing more about your deployment for deeper troubleshooting.

To reply, just mention @dosu.


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

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Dec 31, 2025): <!-- Answer --> The initial latency you’re seeing in Dify 1.11.2 is due to how the code executor now handles HTTP client pooling. On the first request, Dify creates a new HTTP client and establishes the initial connection to the sandbox service, which can involve TLS/DNS handshakes and backend startup—this is what causes the delay. Subsequent requests reuse the pooled client and established connections, so they’re much faster ([source](https://github.com/langgenius/dify/pull/26052), [source](https://github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/api/core/helper/code_executor/code_executor.py#L21-L157)). You can tune these environment variables in your Docker/.env config to optimize pooling and reduce cold start impact: - `CODE_EXECUTION_POOL_MAX_CONNECTIONS` - `CODE_EXECUTION_POOL_MAX_KEEPALIVE_CONNECTIONS` - `CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY` For overall performance, also review: - Celery worker settings (`CELERY_WORKER_AMOUNT`, `CELERY_AUTO_SCALE`) - Database and Redis pool sizes - Server concurrency (`SERVER_WORKER_AMOUNT`, `GRAPH_ENGINE_MAX_WORKERS`) - Disable SSRF proxy if not needed If API calls are still slow, try setting `"response_mode": "streaming"` in your API requests to get incremental results faster ([source](https://github.com/langgenius/dify/discussions/29146)). If the issue persists, check for external network bottlenecks (reverse proxy, Docker network) and consider sharing more about your deployment for deeper troubleshooting. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=The%20initial%20latency%20you%E2%80%99re%20seeing%20in%20Dify%201.11.2%20is%20due%20to%20how%20the%20code%20executor%20now%20handles%20HTTP%20client%20pooling.%20On%20the%20first%20request%2C%20Dify%20creates%20a%20new%20HTTP%20client%20and%20establishes%20the%20initial%20connection%20to%20the%20sandbox%20service%2C%20which%20can%20involve%20TLS/DNS%20handshakes%20and%20backend%20startup%E2%80%94this%20is%20what%20causes%20the%20delay.%20Subsequent%20requests%20reuse%20the%20pooled%20client%20and%20established%20connections%2C%20so%20they%E2%80%99re%20much%20faster%20%28%5Bsource%5D%28https%3A//github.com/langgenius/dify/pull/26052%29%2C%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/api/core/helper/code_executor/code_executor.py%23L21-L157%29%29.%0A%0AYou%20can%20tune%20these%20environment%20variables%20in%20your%20Docker/.env%20config%20to%20optimize%20pooling%20and%20reduce%20cold%20start%20impact%3A%0A-%20%60CODE_EXECUTION_POOL_MAX_CONNECTIONS%60%0A-%20%60CODE_EXECUTION_POOL_MAX_KEEPALIVE_CONNECTIONS%60%0A-%20%60CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY%60%0A%0AFor%20overall%20performance%2C%20also%20review%3A%0A-%20Celery%20worker%20settings%20%28%60CELERY_WORKER_AMOUNT%60%2C%20%60CELERY_AUTO_SCALE%60%29%0A-%20Database%20and%20Redis%20pool%20sizes%0A-%20Server%20concurrency%20%28%60SERVER_WORKER_AMOUNT%60%2C%20%60GRAPH_ENGINE_MAX_WORKERS%60%29%0A-%20Disable%20SSRF%20proxy%20if%20not%20needed%0A%0AIf%20API%20calls%20are%20still%20slow%2C%20try%20setting%20%60%22response_mode%22%3A%20%22streaming%22%60%20in%20your%20API%20requests%20to%20get%20incremental%20results%20faster%20%28%5Bsource%5D%28https%3A//github.com/langgenius/dify/discussions/29146%29%29.%20%0A%0AIf%20the%20issue%20persists%2C%20check%20for%20external%20network%20bottlenecks%20%28reverse%20proxy%2C%20Docker%20network%29%20and%20consider%20sharing%20more%20about%20your%20deployment%20for%20deeper%20troubleshooting.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/30435)
Author
Owner

@zgz757183190 commented on GitHub (Dec 31, 2025):

The initial latency you’re seeing in Dify 1.11.2 is due to how the code executor now handles HTTP client pooling. On the first request, Dify creates a new HTTP client and establishes the initial connection to the sandbox service, which can involve TLS/DNS handshakes and backend startup—this is what causes the delay. Subsequent requests reuse the pooled client and established connections, so they’re much faster (source, source).

You can tune these environment variables in your Docker/.env config to optimize pooling and reduce cold start impact:

  • CODE_EXECUTION_POOL_MAX_CONNECTIONS
  • CODE_EXECUTION_POOL_MAX_KEEPALIVE_CONNECTIONS
  • CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY

For overall performance, also review:

  • Celery worker settings (CELERY_WORKER_AMOUNT, CELERY_AUTO_SCALE)
  • Database and Redis pool sizes
  • Server concurrency (SERVER_WORKER_AMOUNT, GRAPH_ENGINE_MAX_WORKERS)
  • Disable SSRF proxy if not needed

If API calls are still slow, try setting "response_mode": "streaming" in your API requests to get incremental results faster (source).

If the issue persists, check for external network bottlenecks (reverse proxy, Docker network) and consider sharing more about your deployment for deeper troubleshooting.

To reply, just mention @dosu.

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

Chat with Dosu Open in Cursor Join Discord Share on X

1、How to configure these parameters?
CODE_EXECUTION_POOL_MAX_CONNECTIONS
CODE_EXECUTION_POOL_MAX_KEEPALIVE_CONNECTIONS
CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY

2、How to disable the SSRF proxy?

@zgz757183190 commented on GitHub (Dec 31, 2025): > The initial latency you’re seeing in Dify 1.11.2 is due to how the code executor now handles HTTP client pooling. On the first request, Dify creates a new HTTP client and establishes the initial connection to the sandbox service, which can involve TLS/DNS handshakes and backend startup—this is what causes the delay. Subsequent requests reuse the pooled client and established connections, so they’re much faster ([source](https://github.com/langgenius/dify/pull/26052), [source](https://github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/api/core/helper/code_executor/code_executor.py#L21-L157)). > > You can tune these environment variables in your Docker/.env config to optimize pooling and reduce cold start impact: > > * `CODE_EXECUTION_POOL_MAX_CONNECTIONS` > * `CODE_EXECUTION_POOL_MAX_KEEPALIVE_CONNECTIONS` > * `CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY` > > For overall performance, also review: > > * Celery worker settings (`CELERY_WORKER_AMOUNT`, `CELERY_AUTO_SCALE`) > * Database and Redis pool sizes > * Server concurrency (`SERVER_WORKER_AMOUNT`, `GRAPH_ENGINE_MAX_WORKERS`) > * Disable SSRF proxy if not needed > > If API calls are still slow, try setting `"response_mode": "streaming"` in your API requests to get incremental results faster ([source](https://github.com/langgenius/dify/discussions/29146)). > > If the issue persists, check for external network bottlenecks (reverse proxy, Docker network) and consider sharing more about your deployment for deeper troubleshooting. > > _To reply, just mention [@dosu](https://go.dosu.dev/dosubot)._ > > How did I do? [Good](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=other) > > [![Chat with Dosu](https://camo.githubusercontent.com/7c571478962a6b8a5d47cac74b6824c75e4f6731bba52377e6007f9150462923/68747470733a2f2f646f73752e6465762f646f73752d636861742d62616467652e737667)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github) [![Open in Cursor](https://camo.githubusercontent.com/bdf7dbded65ee585887f47e5fd6fa099ea0933088b4b03d02e83b4def50154d4/68747470733a2f2f646f73752e6465762f646f73752d696e2d637572736f722e737667)](https://cursor.com/link/prompt?text=The%20initial%20latency%20you%E2%80%99re%20seeing%20in%20Dify%201.11.2%20is%20due%20to%20how%20the%20code%20executor%20now%20handles%20HTTP%20client%20pooling.%20On%20the%20first%20request%2C%20Dify%20creates%20a%20new%20HTTP%20client%20and%20establishes%20the%20initial%20connection%20to%20the%20sandbox%20service%2C%20which%20can%20involve%20TLS/DNS%20handshakes%20and%20backend%20startup%E2%80%94this%20is%20what%20causes%20the%20delay.%20Subsequent%20requests%20reuse%20the%20pooled%20client%20and%20established%20connections%2C%20so%20they%E2%80%99re%20much%20faster%20%28%5Bsource%5D%28https%3A//github.com/langgenius/dify/pull/26052%29%2C%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/api/core/helper/code_executor/code_executor.py%23L21-L157%29%29.%0A%0AYou%20can%20tune%20these%20environment%20variables%20in%20your%20Docker/.env%20config%20to%20optimize%20pooling%20and%20reduce%20cold%20start%20impact%3A%0A-%20%60CODE_EXECUTION_POOL_MAX_CONNECTIONS%60%0A-%20%60CODE_EXECUTION_POOL_MAX_KEEPALIVE_CONNECTIONS%60%0A-%20%60CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY%60%0A%0AFor%20overall%20performance%2C%20also%20review%3A%0A-%20Celery%20worker%20settings%20%28%60CELERY_WORKER_AMOUNT%60%2C%20%60CELERY_AUTO_SCALE%60%29%0A-%20Database%20and%20Redis%20pool%20sizes%0A-%20Server%20concurrency%20%28%60SERVER_WORKER_AMOUNT%60%2C%20%60GRAPH_ENGINE_MAX_WORKERS%60%29%0A-%20Disable%20SSRF%20proxy%20if%20not%20needed%0A%0AIf%20API%20calls%20are%20still%20slow%2C%20try%20setting%20%60%22response_mode%22%3A%20%22streaming%22%60%20in%20your%20API%20requests%20to%20get%20incremental%20results%20faster%20%28%5Bsource%5D%28https%3A//github.com/langgenius/dify/discussions/29146%29%29.%20%0A%0AIf%20the%20issue%20persists%2C%20check%20for%20external%20network%20bottlenecks%20%28reverse%20proxy%2C%20Docker%20network%29%20and%20consider%20sharing%20more%20about%20your%20deployment%20for%20deeper%20troubleshooting.) [![Join Discord](https://camo.githubusercontent.com/7d2066700925db1e370d956834f9ea0e5bc92cecbe84963fbd2a363e45091b4e/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f6a6f696e2d3538363546323f6c6f676f3d646973636f7264266c6f676f436f6c6f723d7768697465266c6162656c3d)](https://go.dosu.dev/discord-bot) [![Share on X](https://camo.githubusercontent.com/a8bd7f3fcf3f5e3bd124eee9ae50ae2ac17b40971726665ac2121d48f9aee155/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f582d73686172652d626c61636b)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/30435) 1、How to configure these parameters? CODE_EXECUTION_POOL_MAX_CONNECTIONS CODE_EXECUTION_POOL_MAX_KEEPALIVE_CONNECTIONS CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY 2、How to disable the SSRF proxy?
Author
Owner

@dosubot[bot] commented on GitHub (Dec 31, 2025):

To configure the code executor HTTP client pooling in Dify 1.11.2, set these variables in your Docker .env file (or Docker Compose environment section):

CODE_EXECUTION_POOL_MAX_CONNECTIONS=100
CODE_EXECUTION_POOL_MAX_KEEPALIVE_CONNECTIONS=20
CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY=5.0

These control the max total connections, max keep-alive connections, and keep-alive expiry (in seconds) for the code executor’s HTTP client pool. Increase these values if you expect high concurrency or want to keep connections alive longer for performance reasons. After changing them, restart your containers for the changes to take effect.
Reference: .env.example

To disable the SSRF proxy, remove or unset these variables in your .env:

SSRF_PROXY_HTTP_URL=
SSRF_PROXY_HTTPS_URL=

Then, in your docker-compose file, remove the ssrf_proxy service and the ssrf_proxy_network from the networks section of the api, worker, and sandbox services. Also, remove or unset the HTTP_PROXY and HTTPS_PROXY environment variables from the sandbox service.
Reference: docker-compose-template.yaml

Disabling the SSRF proxy removes a security layer that restricts outbound network access from the sandbox. Only do this if you understand and accept the security implications.

To reply, just mention @dosu.


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

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Dec 31, 2025): <!-- Answer --> To configure the code executor HTTP client pooling in Dify 1.11.2, set these variables in your Docker `.env` file (or Docker Compose environment section): ``` CODE_EXECUTION_POOL_MAX_CONNECTIONS=100 CODE_EXECUTION_POOL_MAX_KEEPALIVE_CONNECTIONS=20 CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY=5.0 ``` These control the max total connections, max keep-alive connections, and keep-alive expiry (in seconds) for the code executor’s HTTP client pool. Increase these values if you expect high concurrency or want to keep connections alive longer for performance reasons. After changing them, restart your containers for the changes to take effect. [Reference: .env.example](https://github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/docker/.env.example#L994-L1109) To disable the SSRF proxy, remove or unset these variables in your `.env`: ``` SSRF_PROXY_HTTP_URL= SSRF_PROXY_HTTPS_URL= ``` Then, in your `docker-compose` file, remove the `ssrf_proxy` service and the `ssrf_proxy_network` from the `networks` section of the `api`, `worker`, and `sandbox` services. Also, remove or unset the `HTTP_PROXY` and `HTTPS_PROXY` environment variables from the `sandbox` service. [Reference: docker-compose-template.yaml](https://github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/docker/docker-compose-template.yaml#L23-L366) Disabling the SSRF proxy removes a security layer that restricts outbound network access from the sandbox. Only do this if you understand and accept the security implications. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/c75fe6f7-2497-4e7b-913b-aa6495336adc?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/c75fe6f7-2497-4e7b-913b-aa6495336adc?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/c75fe6f7-2497-4e7b-913b-aa6495336adc?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/c75fe6f7-2497-4e7b-913b-aa6495336adc?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/c75fe6f7-2497-4e7b-913b-aa6495336adc?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/c75fe6f7-2497-4e7b-913b-aa6495336adc?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/c75fe6f7-2497-4e7b-913b-aa6495336adc?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=To%20configure%20the%20code%20executor%20HTTP%20client%20pooling%20in%20Dify%201.11.2%2C%20set%20these%20variables%20in%20your%20Docker%20%60.env%60%20file%20%28or%20Docker%20Compose%20environment%20section%29%3A%0A%0A%60%60%60%0ACODE_EXECUTION_POOL_MAX_CONNECTIONS%3D100%0ACODE_EXECUTION_POOL_MAX_KEEPALIVE_CONNECTIONS%3D20%0ACODE_EXECUTION_POOL_KEEPALIVE_EXPIRY%3D5.0%0A%60%60%60%0A%0AThese%20control%20the%20max%20total%20connections%2C%20max%20keep-alive%20connections%2C%20and%20keep-alive%20expiry%20%28in%20seconds%29%20for%20the%20code%20executor%E2%80%99s%20HTTP%20client%20pool.%20Increase%20these%20values%20if%20you%20expect%20high%20concurrency%20or%20want%20to%20keep%20connections%20alive%20longer%20for%20performance%20reasons.%20After%20changing%20them%2C%20restart%20your%20containers%20for%20the%20changes%20to%20take%20effect.%20%20%0A%5BReference%3A%20.env.example%5D%28https%3A//github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/docker/.env.example%23L994-L1109%29%0A%0ATo%20disable%20the%20SSRF%20proxy%2C%20remove%20or%20unset%20these%20variables%20in%20your%20%60.env%60%3A%0A%0A%60%60%60%0ASSRF_PROXY_HTTP_URL%3D%0ASSRF_PROXY_HTTPS_URL%3D%0A%60%60%60%0A%0AThen%2C%20in%20your%20%60docker-compose%60%20file%2C%20remove%20the%20%60ssrf_proxy%60%20service%20and%20the%20%60ssrf_proxy_network%60%20from%20the%20%60networks%60%20section%20of%20the%20%60api%60%2C%20%60worker%60%2C%20and%20%60sandbox%60%20services.%20Also%2C%20remove%20or%20unset%20the%20%60HTTP_PROXY%60%20and%20%60HTTPS_PROXY%60%20environment%20variables%20from%20the%20%60sandbox%60%20service.%20%20%0A%5BReference%3A%20docker-compose-template.yaml%5D%28https%3A//github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/docker/docker-compose-template.yaml%23L23-L366%29%0A%0ADisabling%20the%20SSRF%20proxy%20removes%20a%20security%20layer%20that%20restricts%20outbound%20network%20access%20from%20the%20sandbox.%20Only%20do%20this%20if%20you%20understand%20and%20accept%20the%20security%20implications.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/30435)
Author
Owner

@zgz757183190 commented on GitHub (Dec 31, 2025):

To configure the code executor HTTP client pooling in Dify 1.11.2, set these variables in your Docker .env file (or Docker Compose environment section):

CODE_EXECUTION_POOL_MAX_CONNECTIONS=100
CODE_EXECUTION_POOL_MAX_KEEPALIVE_CONNECTIONS=20
CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY=5.0

These control the max total connections, max keep-alive connections, and keep-alive expiry (in seconds) for the code executor’s HTTP client pool. Increase these values if you expect high concurrency or want to keep connections alive longer for performance reasons. After changing them, restart your containers for the changes to take effect. Reference: .env.example

To disable the SSRF proxy, remove or unset these variables in your .env:

SSRF_PROXY_HTTP_URL=
SSRF_PROXY_HTTPS_URL=

Then, in your docker-compose file, remove the ssrf_proxy service and the ssrf_proxy_network from the networks section of the api, worker, and sandbox services. Also, remove or unset the HTTP_PROXY and HTTPS_PROXY environment variables from the sandbox service. Reference: docker-compose-template.yaml

Disabling the SSRF proxy removes a security layer that restricts outbound network access from the sandbox. Only do this if you understand and accept the security implications.

To reply, just mention @dosu.

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

Chat with Dosu Open in Cursor Join Discord Share on X

We still encountered errors even after modifying the configuration parameters and disabling the SSRF proxy.

Image Image
@zgz757183190 commented on GitHub (Dec 31, 2025): > To configure the code executor HTTP client pooling in Dify 1.11.2, set these variables in your Docker `.env` file (or Docker Compose environment section): > > ``` > CODE_EXECUTION_POOL_MAX_CONNECTIONS=100 > CODE_EXECUTION_POOL_MAX_KEEPALIVE_CONNECTIONS=20 > CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY=5.0 > ``` > > These control the max total connections, max keep-alive connections, and keep-alive expiry (in seconds) for the code executor’s HTTP client pool. Increase these values if you expect high concurrency or want to keep connections alive longer for performance reasons. After changing them, restart your containers for the changes to take effect. [Reference: .env.example](https://github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/docker/.env.example#L994-L1109) > > To disable the SSRF proxy, remove or unset these variables in your `.env`: > > ``` > SSRF_PROXY_HTTP_URL= > SSRF_PROXY_HTTPS_URL= > ``` > > Then, in your `docker-compose` file, remove the `ssrf_proxy` service and the `ssrf_proxy_network` from the `networks` section of the `api`, `worker`, and `sandbox` services. Also, remove or unset the `HTTP_PROXY` and `HTTPS_PROXY` environment variables from the `sandbox` service. [Reference: docker-compose-template.yaml](https://github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/docker/docker-compose-template.yaml#L23-L366) > > Disabling the SSRF proxy removes a security layer that restricts outbound network access from the sandbox. Only do this if you understand and accept the security implications. > > _To reply, just mention [@dosu](https://go.dosu.dev/dosubot)._ > > How did I do? [Good](https://app.dosu.dev/response-feedback/c75fe6f7-2497-4e7b-913b-aa6495336adc?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/c75fe6f7-2497-4e7b-913b-aa6495336adc?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/c75fe6f7-2497-4e7b-913b-aa6495336adc?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/c75fe6f7-2497-4e7b-913b-aa6495336adc?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/c75fe6f7-2497-4e7b-913b-aa6495336adc?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/c75fe6f7-2497-4e7b-913b-aa6495336adc?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/c75fe6f7-2497-4e7b-913b-aa6495336adc?feedback_type=other) > > [![Chat with Dosu](https://camo.githubusercontent.com/7c571478962a6b8a5d47cac74b6824c75e4f6731bba52377e6007f9150462923/68747470733a2f2f646f73752e6465762f646f73752d636861742d62616467652e737667)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github) [![Open in Cursor](https://camo.githubusercontent.com/bdf7dbded65ee585887f47e5fd6fa099ea0933088b4b03d02e83b4def50154d4/68747470733a2f2f646f73752e6465762f646f73752d696e2d637572736f722e737667)](https://cursor.com/link/prompt?text=To%20configure%20the%20code%20executor%20HTTP%20client%20pooling%20in%20Dify%201.11.2%2C%20set%20these%20variables%20in%20your%20Docker%20%60.env%60%20file%20%28or%20Docker%20Compose%20environment%20section%29%3A%0A%0A%60%60%60%0ACODE_EXECUTION_POOL_MAX_CONNECTIONS%3D100%0ACODE_EXECUTION_POOL_MAX_KEEPALIVE_CONNECTIONS%3D20%0ACODE_EXECUTION_POOL_KEEPALIVE_EXPIRY%3D5.0%0A%60%60%60%0A%0AThese%20control%20the%20max%20total%20connections%2C%20max%20keep-alive%20connections%2C%20and%20keep-alive%20expiry%20%28in%20seconds%29%20for%20the%20code%20executor%E2%80%99s%20HTTP%20client%20pool.%20Increase%20these%20values%20if%20you%20expect%20high%20concurrency%20or%20want%20to%20keep%20connections%20alive%20longer%20for%20performance%20reasons.%20After%20changing%20them%2C%20restart%20your%20containers%20for%20the%20changes%20to%20take%20effect.%20%20%0A%5BReference%3A%20.env.example%5D%28https%3A//github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/docker/.env.example%23L994-L1109%29%0A%0ATo%20disable%20the%20SSRF%20proxy%2C%20remove%20or%20unset%20these%20variables%20in%20your%20%60.env%60%3A%0A%0A%60%60%60%0ASSRF_PROXY_HTTP_URL%3D%0ASSRF_PROXY_HTTPS_URL%3D%0A%60%60%60%0A%0AThen%2C%20in%20your%20%60docker-compose%60%20file%2C%20remove%20the%20%60ssrf_proxy%60%20service%20and%20the%20%60ssrf_proxy_network%60%20from%20the%20%60networks%60%20section%20of%20the%20%60api%60%2C%20%60worker%60%2C%20and%20%60sandbox%60%20services.%20Also%2C%20remove%20or%20unset%20the%20%60HTTP_PROXY%60%20and%20%60HTTPS_PROXY%60%20environment%20variables%20from%20the%20%60sandbox%60%20service.%20%20%0A%5BReference%3A%20docker-compose-template.yaml%5D%28https%3A//github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/docker/docker-compose-template.yaml%23L23-L366%29%0A%0ADisabling%20the%20SSRF%20proxy%20removes%20a%20security%20layer%20that%20restricts%20outbound%20network%20access%20from%20the%20sandbox.%20Only%20do%20this%20if%20you%20understand%20and%20accept%20the%20security%20implications.) [![Join Discord](https://camo.githubusercontent.com/7d2066700925db1e370d956834f9ea0e5bc92cecbe84963fbd2a363e45091b4e/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f6a6f696e2d3538363546323f6c6f676f3d646973636f7264266c6f676f436f6c6f723d7768697465266c6162656c3d)](https://go.dosu.dev/discord-bot) [![Share on X](https://camo.githubusercontent.com/a8bd7f3fcf3f5e3bd124eee9ae50ae2ac17b40971726665ac2121d48f9aee155/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f582d73686172652d626c61636b)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/30435) We still encountered errors even after modifying the configuration parameters and disabling the SSRF proxy. <img width="1920" height="950" alt="Image" src="https://github.com/user-attachments/assets/59344838-be25-495d-9801-a28305ee735d" /> <img width="1749" height="728" alt="Image" src="https://github.com/user-attachments/assets/29414c61-4529-438f-9b2f-d43829737a75" />
Author
Owner

@dosubot[bot] commented on GitHub (Dec 31, 2025):

Since errors are still happening after updating your .env and disabling the SSRF proxy, here are the most likely causes and next steps:

  1. Double-check that you fully removed the SSRF proxy: unset SSRF_PROXY_HTTP_URL and SSRF_PROXY_HTTPS_URL in .env, remove the ssrf_proxy service and ssrf_proxy_network from docker-compose, and unset HTTP_PROXY/HTTPS_PROXY from the sandbox service. Then restart all containers. If any proxy/network config remains, the sandbox may not reach the outside network, causing persistent failures even if pool settings are correct (source).

  2. After config changes, always restart all relevant containers. Dify only reads these environment variables at startup, so changes won’t take effect until a restart (source).

  3. If errors persist, exec into your api, worker, and sandbox containers and test network connectivity (e.g., curl https://www.google.com or to your target endpoint). This will help rule out DNS, firewall, or proxy issues inside Docker (source).

  4. Check the logs from your containers (docker logs <container_name>) for specific error messages or stack traces. The code executor wraps most network/service errors as CodeExecutionError, so logs are key to diagnosing the root cause (source).

If you can share the exact error messages or log output after these steps, I can help pinpoint the issue further. Common causes are incomplete proxy/network removal, missing container restarts, or network/DNS issues inside Docker.

To reply, just mention @dosu.


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

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Dec 31, 2025): <!-- Answer --> Since errors are still happening after updating your .env and disabling the SSRF proxy, here are the most likely causes and next steps: 1. Double-check that you fully removed the SSRF proxy: unset SSRF_PROXY_HTTP_URL and SSRF_PROXY_HTTPS_URL in .env, remove the ssrf_proxy service and ssrf_proxy_network from docker-compose, and unset HTTP_PROXY/HTTPS_PROXY from the sandbox service. Then restart all containers. If any proxy/network config remains, the sandbox may not reach the outside network, causing persistent failures even if pool settings are correct ([source](https://github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/docker/docker-compose-template.yaml#L23-L366)). 2. After config changes, always restart all relevant containers. Dify only reads these environment variables at startup, so changes won’t take effect until a restart ([source](https://github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/api/core/helper/code_executor/code_executor.py#L21-L138)). 3. If errors persist, exec into your api, worker, and sandbox containers and test network connectivity (e.g., `curl https://www.google.com` or to your target endpoint). This will help rule out DNS, firewall, or proxy issues inside Docker ([source](https://github.com/langgenius/dify/issues/26482#issuecomment-3349915185)). 4. Check the logs from your containers (`docker logs <container_name>`) for specific error messages or stack traces. The code executor wraps most network/service errors as CodeExecutionError, so logs are key to diagnosing the root cause ([source](https://github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/api/core/helper/code_executor/code_executor.py#L21-L138)). If you can share the exact error messages or log output after these steps, I can help pinpoint the issue further. Common causes are incomplete proxy/network removal, missing container restarts, or network/DNS issues inside Docker. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/4b51a9f0-9583-4d95-93a7-52a5ee5226fd?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/4b51a9f0-9583-4d95-93a7-52a5ee5226fd?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/4b51a9f0-9583-4d95-93a7-52a5ee5226fd?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/4b51a9f0-9583-4d95-93a7-52a5ee5226fd?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/4b51a9f0-9583-4d95-93a7-52a5ee5226fd?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/4b51a9f0-9583-4d95-93a7-52a5ee5226fd?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/4b51a9f0-9583-4d95-93a7-52a5ee5226fd?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=Since%20errors%20are%20still%20happening%20after%20updating%20your%20.env%20and%20disabling%20the%20SSRF%20proxy%2C%20here%20are%20the%20most%20likely%20causes%20and%20next%20steps%3A%0A%0A1.%20Double-check%20that%20you%20fully%20removed%20the%20SSRF%20proxy%3A%20unset%20SSRF_PROXY_HTTP_URL%20and%20SSRF_PROXY_HTTPS_URL%20in%20.env%2C%20remove%20the%20ssrf_proxy%20service%20and%20ssrf_proxy_network%20from%20docker-compose%2C%20and%20unset%20HTTP_PROXY/HTTPS_PROXY%20from%20the%20sandbox%20service.%20Then%20restart%20all%20containers.%20If%20any%20proxy/network%20config%20remains%2C%20the%20sandbox%20may%20not%20reach%20the%20outside%20network%2C%20causing%20persistent%20failures%20even%20if%20pool%20settings%20are%20correct%20%28%5Bsource%5D%28https%3A//github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/docker/docker-compose-template.yaml%23L23-L366%29%29.%0A%0A2.%20After%20config%20changes%2C%20always%20restart%20all%20relevant%20containers.%20Dify%20only%20reads%20these%20environment%20variables%20at%20startup%2C%20so%20changes%20won%E2%80%99t%20take%20effect%20until%20a%20restart%20%28%5Bsource%5D%28https%3A//github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/api/core/helper/code_executor/code_executor.py%23L21-L138%29%29.%0A%0A3.%20If%20errors%20persist%2C%20exec%20into%20your%20api%2C%20worker%2C%20and%20sandbox%20containers%20and%20test%20network%20connectivity%20%28e.g.%2C%20%60curl%20https%3A//www.google.com%60%20or%20to%20your%20target%20endpoint%29.%20This%20will%20help%20rule%20out%20DNS%2C%20firewall%2C%20or%20proxy%20issues%20inside%20Docker%20%28%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/26482%23issuecomment-3349915185%29%29.%0A%0A4.%20Check%20the%20logs%20from%20your%20containers%20%28%60docker%20logs%20%3Ccontainer_name%3E%60%29%20for%20specific%20error%20messages%20or%20stack%20traces.%20The%20code%20executor%20wraps%20most%20network/service%20errors%20as%20CodeExecutionError%2C%20so%20logs%20are%20key%20to%20diagnosing%20the%20root%20cause%20%28%5Bsource%5D%28https%3A//github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/api/core/helper/code_executor/code_executor.py%23L21-L138%29%29.%0A%0AIf%20you%20can%20share%20the%20exact%20error%20messages%20or%20log%20output%20after%20these%20steps%2C%20I%20can%20help%20pinpoint%20the%20issue%20further.%20Common%20causes%20are%20incomplete%20proxy/network%20removal%2C%20missing%20container%20restarts%2C%20or%20network/DNS%20issues%20inside%20Docker.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/30435)
Author
Owner

@fatelei commented on GitHub (Dec 31, 2025):

The initial latency you’re seeing in Dify 1.11.2 is due to how the code executor now handles HTTP client pooling. On the first request, Dify creates a new HTTP client and establishes the initial connection to the sandbox service, which can involve TLS/DNS handshakes and backend startup—this is what causes the delay. Subsequent requests reuse the pooled client and established connections, so they’re much faster (source, source).

You can tune these environment variables in your Docker/.env config to optimize pooling and reduce cold start impact:

  • CODE_EXECUTION_POOL_MAX_CONNECTIONS
  • CODE_EXECUTION_POOL_MAX_KEEPALIVE_CONNECTIONS
  • CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY

For overall performance, also review:

  • Celery worker settings (CELERY_WORKER_AMOUNT, CELERY_AUTO_SCALE)
  • Database and Redis pool sizes
  • Server concurrency (SERVER_WORKER_AMOUNT, GRAPH_ENGINE_MAX_WORKERS)
  • Disable SSRF proxy if not needed

If API calls are still slow, try setting "response_mode": "streaming" in your API requests to get incremental results faster (source).

If the issue persists, check for external network bottlenecks (reverse proxy, Docker network) and consider sharing more about your deployment for deeper troubleshooting.

To reply, just mention @dosu.

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

Chat with Dosu Open in Cursor Join Discord Share on X

in docker env, the http connect is not slow, just in internal network

@fatelei commented on GitHub (Dec 31, 2025): > The initial latency you’re seeing in Dify 1.11.2 is due to how the code executor now handles HTTP client pooling. On the first request, Dify creates a new HTTP client and establishes the initial connection to the sandbox service, which can involve TLS/DNS handshakes and backend startup—this is what causes the delay. Subsequent requests reuse the pooled client and established connections, so they’re much faster ([source](https://github.com/langgenius/dify/pull/26052), [source](https://github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/api/core/helper/code_executor/code_executor.py#L21-L157)). > > You can tune these environment variables in your Docker/.env config to optimize pooling and reduce cold start impact: > > * `CODE_EXECUTION_POOL_MAX_CONNECTIONS` > * `CODE_EXECUTION_POOL_MAX_KEEPALIVE_CONNECTIONS` > * `CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY` > > For overall performance, also review: > > * Celery worker settings (`CELERY_WORKER_AMOUNT`, `CELERY_AUTO_SCALE`) > * Database and Redis pool sizes > * Server concurrency (`SERVER_WORKER_AMOUNT`, `GRAPH_ENGINE_MAX_WORKERS`) > * Disable SSRF proxy if not needed > > If API calls are still slow, try setting `"response_mode": "streaming"` in your API requests to get incremental results faster ([source](https://github.com/langgenius/dify/discussions/29146)). > > If the issue persists, check for external network bottlenecks (reverse proxy, Docker network) and consider sharing more about your deployment for deeper troubleshooting. > > _To reply, just mention [@dosu](https://go.dosu.dev/dosubot)._ > > How did I do? [Good](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/b7dcf564-e8fd-4874-9987-f34277c05165?feedback_type=other) > > [![Chat with Dosu](https://camo.githubusercontent.com/7c571478962a6b8a5d47cac74b6824c75e4f6731bba52377e6007f9150462923/68747470733a2f2f646f73752e6465762f646f73752d636861742d62616467652e737667)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github) [![Open in Cursor](https://camo.githubusercontent.com/bdf7dbded65ee585887f47e5fd6fa099ea0933088b4b03d02e83b4def50154d4/68747470733a2f2f646f73752e6465762f646f73752d696e2d637572736f722e737667)](https://cursor.com/link/prompt?text=The%20initial%20latency%20you%E2%80%99re%20seeing%20in%20Dify%201.11.2%20is%20due%20to%20how%20the%20code%20executor%20now%20handles%20HTTP%20client%20pooling.%20On%20the%20first%20request%2C%20Dify%20creates%20a%20new%20HTTP%20client%20and%20establishes%20the%20initial%20connection%20to%20the%20sandbox%20service%2C%20which%20can%20involve%20TLS/DNS%20handshakes%20and%20backend%20startup%E2%80%94this%20is%20what%20causes%20the%20delay.%20Subsequent%20requests%20reuse%20the%20pooled%20client%20and%20established%20connections%2C%20so%20they%E2%80%99re%20much%20faster%20%28%5Bsource%5D%28https%3A//github.com/langgenius/dify/pull/26052%29%2C%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/blob/ee1d0df927b8b64baf835b9df1e7aaba62c2cb2c/api/core/helper/code_executor/code_executor.py%23L21-L157%29%29.%0A%0AYou%20can%20tune%20these%20environment%20variables%20in%20your%20Docker/.env%20config%20to%20optimize%20pooling%20and%20reduce%20cold%20start%20impact%3A%0A-%20%60CODE_EXECUTION_POOL_MAX_CONNECTIONS%60%0A-%20%60CODE_EXECUTION_POOL_MAX_KEEPALIVE_CONNECTIONS%60%0A-%20%60CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY%60%0A%0AFor%20overall%20performance%2C%20also%20review%3A%0A-%20Celery%20worker%20settings%20%28%60CELERY_WORKER_AMOUNT%60%2C%20%60CELERY_AUTO_SCALE%60%29%0A-%20Database%20and%20Redis%20pool%20sizes%0A-%20Server%20concurrency%20%28%60SERVER_WORKER_AMOUNT%60%2C%20%60GRAPH_ENGINE_MAX_WORKERS%60%29%0A-%20Disable%20SSRF%20proxy%20if%20not%20needed%0A%0AIf%20API%20calls%20are%20still%20slow%2C%20try%20setting%20%60%22response_mode%22%3A%20%22streaming%22%60%20in%20your%20API%20requests%20to%20get%20incremental%20results%20faster%20%28%5Bsource%5D%28https%3A//github.com/langgenius/dify/discussions/29146%29%29.%20%0A%0AIf%20the%20issue%20persists%2C%20check%20for%20external%20network%20bottlenecks%20%28reverse%20proxy%2C%20Docker%20network%29%20and%20consider%20sharing%20more%20about%20your%20deployment%20for%20deeper%20troubleshooting.) [![Join Discord](https://camo.githubusercontent.com/7d2066700925db1e370d956834f9ea0e5bc92cecbe84963fbd2a363e45091b4e/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f6a6f696e2d3538363546323f6c6f676f3d646973636f7264266c6f676f436f6c6f723d7768697465266c6162656c3d)](https://go.dosu.dev/discord-bot) [![Share on X](https://camo.githubusercontent.com/a8bd7f3fcf3f5e3bd124eee9ae50ae2ac17b40971726665ac2121d48f9aee155/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f582d73686172652d626c61636b)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/30435) in docker env, the http connect is not slow, just in internal network
Author
Owner

@leozanee commented on GitHub (Jan 5, 2026):

#30196 same problem in llm node, This makes me suspect that the high latency in the LLM node is caused by the heavy use of Jinja2 templates and the rendering overhead involved in my workflow.

@leozanee commented on GitHub (Jan 5, 2026): #30196 same problem in llm node, This makes me suspect that the high latency in the LLM node is caused by the heavy use of Jinja2 templates and the rendering overhead involved in my workflow.
Author
Owner

@fatelei commented on GitHub (Jan 6, 2026):

in docker env, dify api docker call dify sandbox use internal network, so the latency will be small, i think this cost is locate at call external site.

Image

i test it, it is very fast

code is


def main():
    import requests
    resp = requests.get("https://www.baidu.com")
    return {"result": resp.text}
@fatelei commented on GitHub (Jan 6, 2026): in docker env, dify api docker call dify sandbox use internal network, so the latency will be small, i think this cost is locate at call external site. <img width="1652" height="1688" alt="Image" src="https://github.com/user-attachments/assets/bf6f94bc-b513-489d-8ed7-3c228198e9ff" /> i test it, it is very fast code is ```python def main(): import requests resp = requests.get("https://www.baidu.com") return {"result": resp.text} ```
Author
Owner

@fatelei commented on GitHub (Jan 6, 2026):

call external use your local network, perhaps you can ping the destination site, check the latency

@fatelei commented on GitHub (Jan 6, 2026): call external use your local network, perhaps you can ping the destination site, check the latency
Author
Owner

@buzhidaojiaoshawww commented on GitHub (Jan 30, 2026):

The HTTP node has the same problem. The first request is delayed by about 15 seconds, but subsequent requests become noticeably faster.

@buzhidaojiaoshawww commented on GitHub (Jan 30, 2026): The HTTP node has the same problem. The first request is delayed by about 15 seconds, but subsequent requests become noticeably faster.
Author
Owner

@fatelei commented on GitHub (Jan 30, 2026):

The HTTP node has the same problem. The first request is delayed by about 15 seconds, but subsequent requests become noticeably faster.

because subsequent reuse the connection pool, so it fast, but first request has no connection pool

@fatelei commented on GitHub (Jan 30, 2026): > The HTTP node has the same problem. The first request is delayed by about 15 seconds, but subsequent requests become noticeably faster. because subsequent reuse the connection pool, so it fast, but first request has no connection pool
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#21392