End-to-End Performance Optimization of a High-Concurrency SSM E‑Commerce System

Online system performance tuning is a technical activity that requires strong practical skills, problem‑identification, and deep optimization expertise.

This article shares a complete, hands‑on walkthrough of a high‑concurrency tuning cycle for an SSM‑based e‑commerce project, from problem identification to monitoring the results.

1. Project Overview

The project is a single‑module SSM architecture with a flash‑sale module. The deployment includes 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.

Call flow diagram (image omitted) shows how requests travel through the system.

2. What Is a Monolithic Architecture?

The article outlines the evolution of software architectures: monolithic (no front‑back separation), vertical (front‑back separation), SOA (service‑oriented), and microservices (multiple small projects). Diagrams illustrate each stage.

3. Problems Encountered in the SSM Project

During flash‑sale periods (10 am, 1 pm, 8 pm) the CPU spikes dramatically, request counts exceed 3000 per server, Redis shows ~600 connected clients, and MySQL experiences high request latency. Screenshots of the flash‑sale page, CPU usage, Redis connections, and MySQL queries are included.

4. Investigation Process and Analysis

(a) Investigation Scope

Check memory, CPU, request volume, and connection counts on application servers, image servers, timer servers, Redis, and DB servers.

(b) Findings

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

Redis requests timed out.

JDBC connections timed out.

Full GC occurred 152 times in 24 hours.

Thread dumps revealed blocking and dead‑lock situations.

More than 2000 threads were requesting invalid resources.

Tools used include jstat -l pid , VisualVM, and thread stack analysis.

(c) Root‑Cause Analysis

Request burst during flash‑sale 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

1. Add more application instances and perform traffic shaping/partitioning (hard load‑balancing due to lack of MQ).

2. Optimize JVM parameters. Example:

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"

3. Tune Tomcat concurrency (switch BIO to NIO2, adjust thread pool settings).

4. Optimize Redis and JDBC parameters (details omitted for security).

5. Code optimizations:

Remove large object allocations.

Ensure timely release of objects and connections.

6. Increase cache size in conf/context.xml :

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

6. Optimization Results

After several days of observation the system stabilized. Monitoring charts show improved CPU, memory, and GC behavior.

7. Summary

The article demonstrates a full‑cycle, practical approach to high‑concurrency tuning, but also notes long‑term architectural concerns: tight front‑back coupling, lack of microservice isolation, no traffic shaping, non‑high‑availability Redis, and the need for better scalability designs.