A Performance Analysis of Pulling Rate Based on Image Layer Concurrency Level in Docker Environment for Cold Start Mitigation
Annual Conference of KIPS (ACK 2023)
More parallel downloads do not always mean faster image pulls. We varied image size, registry location, and layer concurrency to measure the trade-off.
- Role
- Co-author · image-pulling performance analysis
- Outcome
- At 10Mbps with ten layers, concurrency of 5–7 generally worked well; the 10MB Tokyo case continued improving at higher concurrency.
Background
Much of a serverless cold start — the delay of initializing and launching a container the first time a function runs — is spent pulling the container image from a remote registry. Reduce the pulling cost and the cold-start delay drops with it.
This paper analyzes whether adjusting how many image layers Docker pulls concurrently (the concurrency level, default 3) can improve pulling speed.
Experiment
On Tencent Cloud, a client sat in Seoul with private Docker registries in Tokyo, Bangkok, and Silicon Valley (nearest to farthest). Images of 10 MB, 100 MB, and 500 MB — each made of ten layers of 1 MB, 10 MB, and 50 MB — were deployed to each registry.
On a 10 Mbps link (Intel Xeon Cascade Lake, Ubuntu 22.04), pull time was measured with `time docker pull` while sweeping the concurrency level over 1, 3, 5, 7, 9, and 10 — clearing the cache each run and repeating 10 times in two different time windows.
Results
On the tested 10Mbps link, parallel downloads were faster than serial downloads, with concurrency of 5–7 generally favorable. Beyond that, gains flattened or reversed.
The 10MB Tokyo case continued improving at higher concurrency. Because image size and registry location changed the result, concurrency needs to be measured for the deployment environment.