How Alibaba Cloud’s Function Compute Cuts Container Image Pull Times by Up to 80%

Background

Container images are the de‑facto standard for cloud‑native deployments. Major Function‑as‑a‑Service platforms such as Alibaba Cloud Function Compute and AWS Lambda added support for container images in 2020, enabling workloads like machine‑learning inference, media processing, event‑driven batch jobs, and front‑end automation. Cold‑start latency is dominated by pulling and extracting large images, which can take minutes for gigabyte‑scale images.

Why image pull is slow

An OCI V1 image consists of multiple compressed layers (tar.gz). Pulling an image requires:

Downloading each layer fully.

Sequentially decompressing each layer.

Merging the layers into the root filesystem.

Key inefficiencies:

Gzip compression prevents random access, forcing full‑layer downloads and single‑threaded decompression.

Gzip decompression is roughly nine times slower than modern algorithms such as LZ4.

All layers are transferred even if the application never uses the data, leading to unnecessary network traffic.

Function Compute Image Acceleration

Alibaba Cloud leverages its internal container‑storage and acceleration technology to offload image‑optimization to the Function Compute service. The service automatically creates an accelerated version of the original image, caches it, and serves it to functions. Acceleration is available in Hangzhou, Beijing, Shanghai, US‑East, and US‑West regions.

Acceleration principles

On‑demand loading : Only the data actually accessed by the function is fetched. The original layer‑based image is transformed into a fine‑grained, on‑demand readable format stored in a high‑throughput backend. Benchmarks show data‑loading rates between 12 % and 84 % of the total image size.

Efficient decompression : The accelerated format uses faster compression algorithms, reducing decompression time by >60 % even when >70 % of the image is loaded.

Benchmark results

Seven workloads (web, e‑commerce, machine‑learning, AI inference, headless Chrome PDF generation, UI automation) were deployed in the FC Beijing region. Enabling image acceleration consistently reduced pull time by more than 50 %; for large ML images the reduction reached 70 %–86 %.

Sample benchmark data

python‑flask (Web app): compressed 46 MB, uncompressed 118 MB.

ecommerce‑nodejs (Node.js Express): 130 MB → 371 MB.

ml‑small‑import / ml‑large‑import (ML libraries): 728 MB → 2.392 GB.

ai‑cat‑or‑dog (TensorFlow/Keras inference): 790 MB → 1.824 GB.

puppeteer‑pdf (Headless Chrome PDF): 332 MB → 894 MB.

cypress‑chrome (UI automation): 980 MB → 2.608 GB.

How to enable acceleration

Acceleration can be turned on via the Function Compute console, CLI, or SDK.

Console : Open the function configuration and toggle “Enable Image Acceleration”.

CLI / SDK : Add AccelerationType: Default to the CustomContainerConfig. Omit the field or set a different value to disable.

CustomContainerConfig:
  Image: registry-vpc.cn-beijing.aliyuncs.com/fc-demo/python-flask:v0.1
  AccelerationType: Default

Feature highlights

Zero‑code activation; accelerated images are created and cached automatically (typically within five minutes).

Developers no longer need to manually trim images or maintain separate Serverless‑compatible builds.

The service incurs no extra charge; reduced pull time also lowers request‑related costs.

Combined with FaaS elasticity, cold‑start latency can drop from minutes to seconds, enabling real‑time workloads.

Future roadmap

Function Compute will continue to refine cold‑start performance, extending acceleration to additional stages of the startup pipeline and further reducing latency for real‑time serverless applications.