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.

翻译：容器启动延迟是CI/CD流水线、无服务器计算和自动扩缩容系统的关键性能指标，然而从业者缺乏关于基础设施选择如何影响该延迟的实证指导。我们提出一项系统性测量研究，将Docker容器启动过程分解为三个异构基础设施层级上的组成操作：Azure高级SSD（云端SSD）、Azure标准HDD（云端HDD）以及macOS Docker Desktop（基于管理程序的虚拟化开发工作站）。通过使用可复现的基准测试套件（每个测试执行50次迭代，涵盖10个性能维度），我们量化了先前未被充分表征的基础设施配置与容器运行时行为之间的关系。主要发现包括：（1）容器启动时间主要受运行时开销而非镜像大小影响，在SSD存储上5 MB至155 MB的镜像仅产生2.5%的启动时间差异；（2）存储层级选择导致2.04倍的启动延迟惩罚（HDD 1157 ms vs. SSD 568 ms）；（3）Docker Desktop的管理程序层引入2.69倍的启动延迟惩罚，且CPU节流方差较原生Linux高9.5倍；（4）与SSD存储上的卷挂载相比，OverlayFS写入性能最多下降两个数量级；（5）Linux命名空间创建仅贡献8-10 ms（<1.5%）的总启动时间。所有测量脚本、原始数据与分析工具均已公开。