[Bug]: DoclingReader takes too much time to get documents when launched from Docker container

[maxvelichko26]

Bug Description

I am currently working on a RAG system, which query engine uses both VectorIndexRetriever and bm25retriever. For latter one I require nodes, which I try to generate from files that I gather from MinioReader that uses DoclingReader as file_extractor.
When I am running load_data() natively it takes about 4 minutes to extract about 170 .docx and .xlsx files from minio container. But when launched from inside docker container application, process takes more than an hour.
What could be the cause of this? Docker container has no constraints on resourses and I even added GPU to deploy in docker-compose file.

Version

llama-index-readers-docling = 0.4.1

Steps to Reproduce

Just build a docker app with 2 containers: minio and main, put some files inside minio, then try extracting them with following script:

For comparison, try the same without putting the script inside docker, for example, launch from jupyter notebook

Calling nodes from minio via next function:
def get_documents_minio():
file_extr = {}
reader = DoclingReader(export_type=DoclingReader.ExportType.MARKDOWN, doc_converter= DocumentConverter())
for val in ['.pdf', '.vdx', '.docx', '.xlsx']:
file_extr[val] = reader
minio_reader = MinioReader(
bucket='example',
minio_endpoint='127.0.0.1:9000',
minio_access_key="minioadmin",
minio_secret_key="minioadmin",
file_extractor= file_extr,
)

  documents = minio_reader.load_data() 

return documents

Relevant Logs/Tracbacks

Don't know about relevancy, but docker logs just show Reader working on documents for a long time, between seconds and multiple minutes.

2025-10-01 15:27:35 2025-10-01 12:27:35,230 - INFO - deleted item in tree at stack: (597,) => #/texts/644
2025-10-01 15:27:35 2025-10-01 12:27:35,247 - INFO - deleted item in tree at stack: (597,) => #/texts/644
2025-10-01 15:27:35 2025-10-01 12:27:35,263 - INFO - deleted item in tree at stack: (597,) => #/texts/644
2025-10-01 15:27:35 2025-10-01 12:27:35,280 - INFO - deleted item in tree at stack: (597,) => #/texts/644
2025-10-01 15:27:35 2025-10-01 12:27:35,298 - INFO - deleted item in tree at stack: (597,) => #/texts/644
2025-10-01 15:27:35 2025-10-01 12:27:35,324 - INFO - deleted item in tree at stack: (597,) => #/texts/646
2025-10-01 15:27:35 2025-10-01 12:27:35,341 - INFO - deleted item in tree at stack: (597,) => #/texts/646
2025-10-01 15:27:35 2025-10-01 12:27:35,358 - INFO - deleted item in tree at stack: (597,) => #/texts/646
2025-10-01 15:27:35 2025-10-01 12:27:35,375 - INFO - deleted item in tree at stack: (597,) => #/texts/646
2025-10-01 15:27:35 2025-10-01 12:27:35,391 - INFO - deleted item in tree at stack: (597,) => #/texts/646
2025-10-01 15:27:35 2025-10-01 12:27:35,416 - INFO - deleted item in tree at stack: (597,) => #/texts/648
2025-10-01 15:27:35 2025-10-01 12:27:35,432 - INFO - deleted item in tree at stack: (597,) => #/texts/648
2025-10-01 15:27:35 2025-10-01 12:27:35,448 - INFO - deleted item in tree at stack: (597,) => #/texts/648
2025-10-01 15:27:35 2025-10-01 12:27:35,464 - INFO - deleted item in tree at stack: (597,) => #/texts/648
2025-10-01 15:27:35 2025-10-01 12:27:35,481 - INFO - deleted item in tree at stack: (597,) => #/texts/648
2025-10-01 15:27:35 2025-10-01 12:27:35,507 - INFO - deleted item in tree at stack: (597,) => #/texts/650
2025-10-01 15:27:35 2025-10-01 12:27:35,523 - INFO - deleted item in tree at stack: (597,) => #/texts/650
2025-10-01 15:27:35 2025-10-01 12:27:35,540 - INFO - deleted item in tree at stack: (597,) => #/texts/650
2025-10-01 15:27:35 2025-10-01 12:27:35,564 - INFO - deleted item in tree at stack: (604,) => #/texts/656
2025-10-01 15:27:35 2025-10-01 12:27:35,580 - INFO - deleted item in tree at stack: (604,) => #/texts/656
2025-10-01 15:27:35 2025-10-01 12:27:35,598 - INFO - deleted item in tree at stack: (604,) => #/texts/656
2025-10-01 15:27:35 2025-10-01 12:27:35,616 - INFO - deleted item in tree at stack: (604,) => #/texts/656
2025-10-01 15:27:35 2025-10-01 12:27:35,633 - INFO - deleted item in tree at stack: (604,) => #/texts/656
2025-10-01 15:27:35 2025-10-01 12:27:35,649 - INFO - deleted item in tree at stack: (604,) => #/texts/656
2025-10-01 15:27:35 2025-10-01 12:27:35,666 - INFO - deleted item in tree at stack: (604,) => #/texts/656
2025-10-01 15:27:35 2025-10-01 12:27:35,682 - INFO - deleted item in tree at stack: (604,) => #/texts/656
2025-10-01 15:27:35 2025-10-01 12:27:35,699 - INFO - deleted item in tree at stack: (604,) => #/texts/656

[dosubot]

The slowdown you're seeing in Docker is likely due to two main factors: network overhead and disk I/O. MinioReader downloads each file from Minio one-by-one to a temporary directory inside the container, so any extra network latency between containers (especially with Docker's default bridge network) gets multiplied by the number of files. Disk I/O for temporary storage can also be much slower in containers, especially if the temp directory is on an overlay filesystem or a slow volume mount. There is no parallelization in the download process, so these bottlenecks add up quickly with large batches of files. You can review the MinioReader implementation for details on how files are handled and why these issues arise here.

To mitigate this, try running your containers with host networking, optimizing your temp directory location (e.g., mounting a fast volume for /tmp), or batching/paralleling downloads if possible. Also, check for any differences in dependencies or subprocess handling in DoclingReader, as Docker can sometimes miss system packages needed for document conversion.

There is a known bug in earlier versions of llama-index-readers-docling that affects how binary streams are handled, but this mainly impacts error handling rather than performance. Still, if your workflow relies on streams, make sure your version isn't affected by this issue.

To reply, just mention @dosu.

---

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

[maxvelichko26]

@dosu Could you provide an example how to mount a fast volume for /tmp?

[dosubot]

Mounting a fast volume for /tmp can significantly improve disk I/O performance in Docker, which is important for workloads like DoclingReader/MinioReader that do a lot of temporary file operations.

Here are some common ways to mount a fast volume for /tmp:

1. Use a tmpfs (memory-backed, fastest, not persistent):

• With docker run:

  docker run --mount type=tmpfs,destination=/tmp myimage
  

• With docker-compose.yml:

  services:
    app:
      image: myimage
      tmpfs:
        - /tmp

2. Use a host directory (persistent, depends on host disk speed):

• With docker run (replace /host/tmp-fast with a fast SSD-backed directory on your host):

  docker run -v /host/tmp-fast:/tmp myimage
  

• With docker-compose.yml:

  services:
    app:
      image: myimage
      volumes:
        - /host/tmp-fast:/tmp

3. Use a Docker-managed named volume (persistent, managed by Docker):

• With docker run:

  docker volume create tmpfast
  docker run -v tmpfast:/tmp myimage
  

• With docker-compose.yml:

  services:
    app:
      image: myimage
      volumes:
        - tmpfast:/tmp
  volumes:
    tmpfast:

Notes:

• tmpfs is the fastest but uses RAM and is not persistent across container restarts.
• Host directory and named volume are persistent, but speed depends on the underlying storage.
• On Windows/Mac, path syntax for host directories may differ.
• Make sure permissions allow your container to write to the mounted directory.

Let me know if you want a more tailored example for your OS or setup!

To reply, just mention @dosu.

---

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

[logan-markewich]

Docling also relies on external modules that are downloaded at runtime. Locally you probably have them cached, but in the docker container, they probably need to download again

I would also triple check you don't have any CPU/RAM/GPU limitations in your container env