Search papers, labs, and topics across Lattice.
This paper presents a systematic measurement study decomposing Docker container startup latency across three infrastructure tiers: Azure Premium SSD, Azure Standard HDD, and macOS Docker Desktop. The study quantifies the impact of infrastructure choices on container runtime behavior, revealing that runtime overhead dominates startup time, storage tier selection significantly impacts startup latency, and Docker Desktop's hypervisor introduces substantial performance penalties. Key findings include a 2.04x startup penalty for HDD vs. SSD and a 2.69x penalty for Docker Desktop compared to native Linux.
Ditch the large container images – this study reveals that runtime overhead, not image size, is the real bottleneck in Docker container startup, and your storage tier choice matters far more than you think.
Container startup latency is a critical performance metric for CI/CD pipelines, serverless computing, and auto-scaling systems, yet practitioners lack empirical guidance on how infrastructure choices affect this latency. We present a systematic measurement study that decomposes Docker container startup into constituent operations across three heterogeneous infrastructure tiers: Azure Premium SSD (cloud SSD), Azure Standard HDD (cloud HDD), and macOS Docker Desktop (developer workstation with hypervisor-based virtualization). Using a reproducible benchmark suite that executes 50 iterations per test across 10 performance dimensions, we quantify previously under-characterized relationships between infrastructure configuration and container runtime behavior. Our key findings include: (1) container startup is dominated by runtime overhead rather than image size, with only 2.5% startup variation across images ranging from 5 MB to 155 MB on SSD; (2) storage tier selection imposes a 2.04x startup penalty (HDD 1157 ms vs. SSD 568 ms); (3) Docker Desktop's hypervisor layer introduces a 2.69x startup penalty and 9.5x higher CPU throttling variance compared to native Linux; (4) OverlayFS write performance collapses by up to two orders of magnitude compared to volume mounts on SSD-backed storage; and (5) Linux namespace creation contributes only 8-10 ms (<1.5%) of total startup time. All measurement scripts, raw data, and analysis tools are publicly available.
