Online High‑Concurrency Performance Tuning of an SSM‑Based E‑Commerce Application

Online system tuning is a technical activity that requires strong practical skills, problem‑identification, location, and investigation abilities, as well as rich optimization experience.

This article shares the entire closed‑loop process of high‑concurrency tuning for an online flash‑sale system from a practical perspective, covering problem identification, location, analysis, solution proposal, implementation, monitoring, and post‑tuning observation.

1. Project Brief Overview

The project is a monolithic e‑commerce application built on the SSM framework, featuring a heavy flash‑sale module. The current online environment architecture includes one load‑balancer (F5), three application servers, one timer server, one Redis server, one image server, and a MySQL master‑slave cluster on Microsoft Cloud.

Call logic diagram:

2. What Is a Monolithic Architecture Project

From the perspective of architectural evolution, software projects have passed through several stages:

Monolithic architecture: traditional non‑separated front‑end and back‑end.

Vertical architecture: front‑end and back‑end separation.

SOA architecture: service‑oriented, dividing a large ERP into order, procurement, material, and sales services.

Micro‑service architecture: each service becomes an independent small project with its own deployment and inter‑service calls.

3. Online Issues Caused by the SSM Project

1. CPU spikes during flash‑sale.

The flash‑sale occurs at three daily time slots (10:00, 13:00, 20:00). Screenshots of the flash‑sale pages (Figures 1‑3) show massive traffic.

2. CPU usage on a single application server.

3. Request count on a single application server.

4. Redis connections (info clients) – about 600.

connected_clients:600

5. MySQL request screenshot.

4. Investigation Process and Analysis

(1) Investigation ideas

Based on the deployment and architecture, the following components were examined:

Application servers – memory, CPU, request count.

Image servers – memory, CPU, request count.

Timer server – memory, CPU, request count.

Redis server – memory, CPU, connection count.

Database server – memory, CPU, connection count.

(2) Investigation steps

Within 30 minutes after a flash‑sale:

Application server CPU and memory surged because request count exceeded 3 000 per server.

Redis request timeouts were observed.

JDBC connection timeouts occurred.

Full GC happened 152 times within 24 hours.

Thread dumps revealed blocked threads and deadlocks (checked via jstat -l pid or VisualVM).

More than 2 000 threads were requesting invalid resources.

Key root causes identified:

Excessive request volume during flash‑sale overloads application servers.

Redis connection pool exhaustion – “cannot get a connection from thread pool”.

JDBC connection pool exhaustion and timeouts.

Large object allocations causing frequent Full GC.

Improper Tomcat concurrency, 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. Since the project lacks a message queue, horizontal scaling with hard load‑balancing was used.

2. Optimize JVM parameters.

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"

Further analysis of JVM theory and official recommendations will be covered in a follow‑up article.

3. Optimize Tomcat concurrency parameters. Two main actions:

Switch BIO protocol to NIO2.

Adjust parameters according to server capacity and traffic to achieve optimal performance.

4. Redis and JDBC parameter tuning. (Details omitted for security reasons.)

5. Code optimization.

Remove large objects that cause memory pressure.

Ensure timely release of objects and connection resources.

6. Resolve >2 000 threads requesting invalid resources. Increase cache size in conf/context.xml :

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

6. Final Optimization Results

After several days of observation, the system remained stable.

1. Basic monitoring.

2. GC statistics.

3. CPU and memory sampling.

7. Summary

This article shared the end‑to‑end process of high‑concurrency tuning, from problem identification to solution implementation and post‑tuning observation. Some details were omitted due to length.

Long‑term concerns remain:

Tight front‑end/back‑end coupling without separation.

No architectural adjustments for localized high‑concurrency traffic.

Flash‑sale logic tightly coupled with the monolithic codebase, lacking isolation.

Missing traffic shaping/limiting mechanisms such as MQ.

Redis not deployed as a high‑availability cluster.