Taming CPU Spikes in a High‑Traffic SSM E‑Commerce App: End‑to‑End Tuning

1 Project Overview

The project is a monolithic e‑commerce application built on the SSM stack (Spring, Spring MVC, MyBatis). It includes a heavy‑traffic flash‑sale module. The deployment consists of one load‑balancer (F5), three application servers, a timer server, a Redis server, an image server, and a MySQL master‑slave cluster on Microsoft Cloud.

2 What Is a Monolithic Architecture

From an architectural evolution perspective, software projects progress through:

Monolithic architecture – traditional tightly coupled front‑end and back‑end.

Vertical architecture – front‑end and back‑end separated.

SOA – services organized by business domain.

Microservices – many small, independent projects.

3 Issues Encountered

During flash‑sale periods (10:00, 13:00, 20:00) the system exhibited:

CPU spikes on the application servers.

High request counts (over 3000 per server).

Redis connection count around 600.

MySQL request bottlenecks.

4 Investigation Process and Analysis

(1) Investigation Approach

Check memory, CPU, request volume, and connection counts on each server tier (application, image, timer, Redis, DB).

(2) Findings

Application servers’ CPU and memory surged due to excessive request volume (≈3000 per server).

Redis requests timed out.

JDBC connections timed out.

Full GC occurred 152 times in 24 hours.

Thread dumps revealed blocked threads and deadlocks.

Over 2000 threads were requesting invalid resources.

(3) Root‑Cause Analysis

Excessive request volume during flash sales overloaded application servers.

Redis connection pool exhausted.

JDBC connection pool exhausted.

Large objects kept in memory caused frequent Full GC.

Sub‑optimal Tomcat, JVM, Jedis, and JDBC parameters.

No traffic‑shaping or rate‑limiting.

Resources (Redis, JDBC) not released promptly.

5 Final Solutions

Scale out application servers and implement traffic‑shaping (hard load‑balancing) to distribute load.

Optimize JVM options:

JAVA_OPTS="-server -Xmx9g -Xms9g -Xmn3g -Xss500k -XX:+DisableExplicitGC -XX:MetaspaceSize=2048m -XX:MaxMetaspaceSize=2048m -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -Dfile.encoding=UTF8 -Duser.timezone=GMT+08"

Switch Tomcat connector to NIO2 and tune concurrency parameters (details omitted, to be covered in a follow‑up article).

Adjust Redis and JDBC pool settings (specific values omitted for security).

Code refactoring: eliminate large objects, ensure timely release of resources.

Increase Tomcat cache size in conf/context.xml:

<Resource cachingAllowed="true" cacheMaxSize="102400"/>

6 Final Optimization Results

After several days of observation the system stabilized:

Basic monitoring metrics returned to normal.

GC activity reduced dramatically.

CPU and memory usage remained within acceptable ranges.

7 Summary

The article presented a complete end‑to‑end tuning workflow for a high‑concurrency SSM e‑commerce system, from problem detection to solution implementation and post‑tuning monitoring. While the immediate issues were resolved, the monolithic design still poses long‑term risks such as tight front‑back coupling, lack of isolated flash‑sale modules, absence of traffic‑shaping mechanisms, and missing Redis high‑availability clustering.