How We Cut Application Deployment Time by 70%: A Step‑by‑Step Case Study

1. Overview

The company’s safety production standards require a 1‑minute response, 5‑minute定位, and 10‑minute resolution (1‑5‑10). Deployment time directly impacts both incident recovery and daily development efficiency. The omega application’s average deployment time was about 229 seconds (≈3 minutes), with some older apps exceeding 5 minutes.

2. Current Deployment Status

The January pre‑release environment for omega showed an average startup time of 229 seconds, requiring 7–8 minutes to deploy two machines.

3. Optimization Measures

3.1 Application Startup Log Analysis

Each application differs; the following analysis uses omega as an example.

By reviewing startup logs, unnecessary components were identified and removed.

3.1.1 Remove liaoyuan Middleware

traceId:2024-03-05 18:02:04,957 INFO Loading XML bean definitions from class path resource [platform/liaoyuan.xml]

liaoyuan was only used by a low‑traffic interface and was disabled, allowing the entire module to be taken offline.

3.1.2 Eliminate Unused Notify Packages

Logs showed “.ear/.spring/.war” packages and notify‑related classes that had already been deprecated. Removing NotifyManagerBean or disabling its reliable async send manager eliminated these warnings.

3.1.3 Remove doom Module

The doom module was never used; its startup failure was resolved by removing the module entirely.

3.1.4 Fix Log4j Configuration

Druid defaulted to Log4j while the project uses SLF4J + Logback. Adding the JVM parameter -Ddruid.logType=slf4j aligned logging components.

3.1.5 Deactivate AutoConfig Module

AutoConfig, a legacy configuration manager, has been migrated to Diamond; no immediate changes were made pending further verification.

3.2 Application Startup Diagnosis Platform

The ICBU transaction team and architecture team built a startup‑optimization platform that collects launch data, generates detailed reports, and offers automatic diagnosis and recommended solutions.

3.2.1 Upgrade aspectjrt Version

org.springframework.aop.aspectj.AspectJExpressionPointcut matches took 6014 ms.

Updating aspectjrt and aspectjweaver reduced AOP‑related startup latency.

3.2.2 Remove Non‑existent HSF Consumers

HSF providers had been taken offline, but some consumers remained configured. These were identified and removed to avoid unnecessary initialization.

3.3 Startup Data Reporting

The platform also produced a comprehensive startup data report, highlighting beans with long initialization times.

3.3.1 Remove Unused Spring Beans

Beans such as UserCacheService that were never referenced were deleted.

3.3.2 Asynchronous Bean Creation

The async‑bean‑startup‑starter component allows non‑critical beans to be created asynchronously, reducing blocking time.

3.4 Startup Script Diagnosis

3.4.1 Offline_hsf Repeated Execution

SHELL script: start.sh → appctl.sh → offline_hsf total time = 40 s (executed twice).

Identified redundant offline_hsf calls and optimized the scripts. After script changes, the Docker image must be rebuilt to apply updates.

4. Final Results

After applying all optimizations, omega’s deployment time dropped from 229 seconds to 69.71 seconds, achieving a 69% improvement.