Docker daemon concurrency limits affecting image pull latency

The Docker daemon utilizes the max-concurrent-downloads and max-concurrent-uploads settings to manage the parallel transfer of image layers. By default, these limits are set to three concurrent operations. In high-density environments such as CI/CD runners or autoscaling nodes, multiple simultaneous container creations often trigger image pulls that exceed this default threshold.

While these settings specifically address the transfer phase, they can manifest as significant latency when layers are queued waiting for available concurrency slots. It remains unclear whether the bottleneck in these scenarios is strictly the daemon-side queue or if the performance degradation shifts to resource exhaustion like disk I/O during the layer extraction phase.

How does the Docker daemon prioritize layer requests when the max-concurrent-downloads limit is reached? Is there a documented method to determine if pull latency is caused by the transfer throttle or the subsequent decompression and filesystem extraction process?