How Alibaba Cloud SAE Gets Lightning‑Fast Startup via Image Caching & CPU Burst

Introduction

In modern cloud environments, rapid scaling and high availability are essential for competitive services. Alibaba Cloud’s Serverless Application Engine (SAE) addresses these needs by introducing several performance‑enhancing techniques that reduce image pull time, accelerate container startup, and optimize CPU usage.

Impact of Image Pull Time

The time required to pull a container image directly determines how quickly a new SAE instance can serve traffic. Without acceleration, pulling base images such as ARMS or SLS can exceed 10 seconds, which is unacceptable for many workloads.

Image Caching Solutions

Solution 1: Image Pre‑heating

SAE uses a DADI‑based peer‑to‑peer (P2P) network to pre‑heat images. The DADI system builds a tree‑structured overlay where each node has a fixed maximum number of children, providing predictable depth and balanced load. During deployment, the ROOT node receives the image data, and agents pull from their parent nodes, ensuring that the image is already cached when the instance starts.

Solution 2: ImageCache CRD

SAE creates a custom resource definition (CRD) that downloads frequently used base images to Kubernetes worker nodes in advance. When a user’s container needs the image, it can be served from the local cache, eliminating remote pull latency.

DADI On‑Demand Block Loading

Traditional layered images require downloading entire layers even if only a small portion of the data is needed, leading to unnecessary I/O and longer startup times. DADI replaces the file‑system‑based image format with a block‑device format. Each layer stores block‑level differences, and the overlaybd module assembles these layers into a virtual block device that can be read at sector granularity.

Tests conducted internally showed that DADI’s on‑demand loading dramatically reduces startup latency, especially when the application accesses only a small subset of the image data.

Code Package Deployment Process

User uploads a JAR or WAR package, which SAE stores in OSS.

SAE’s image build service pulls the package and builds a container image, pushing it to the internal image registry.

An acceleration conversion service transforms the image into an accelerated version.

The accelerated image is stored in a dedicated repository and is preferentially pulled by instances at runtime, with no cost to the user.

Java Application Startup Acceleration

SAE leverages the Dragonwell 11 runtime’s quickstart feature. The application process runs twice:

Tracer phase: The first run records execution data to a cache file (automatically on exit or via jcmd QuickStart.dump).

Replayer phase: The second run reads the cache file, allowing the JVM to skip redundant work and start faster.

Runtime Acceleration with Wisp2

SAE also enables coroutine‑based execution using Alibaba’s Wisp2 implementation. When the -XX:+UseWisp2 flag is set, the JVM injects additional parameters that improve asynchronous performance.

-XX:-UseBiasedLocking
-XX:+EnableCoroutine
-XX:+UseWispMonitor
-Dcom.alibaba.transparentAsync=true
-Dcom.alibaba.shiftThreadModel=true
-Dcom.alibaba.wisp.version=2
-Dcom.alibaba.wisp.allThreadAsWisp=true

CPU Burst

CPU Burst temporarily doubles the CPU limit for an instance during the first three minutes after startup, then reverts to the configured limit. This allows resource‑intensive initialization to complete quickly without permanently allocating excess CPU capacity.

Documentation for enabling CPU Burst can be found at the official Alibaba Cloud help page.

Conclusion

SAE’s combination of image pre‑heating, on‑demand block loading, accelerated code‑package deployment, Java quick‑start, coroutine runtime, and CPU Burst provides a comprehensive acceleration stack that significantly reduces startup latency and improves overall resource efficiency for cloud‑native applications.