End-to-End Online High-Concurrency Tuning for a Monolithic SSM E‑Commerce System

This article approaches online system optimization from a practical perspective, describing the complete closed‑loop process of high‑concurrency tuning: problem identification,定位, analysis, solution proposal, implementation, monitoring, and post‑tuning observation.

Project Overview

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

What Is a Monolithic Architecture?

From the evolution of software architecture, the article briefly defines monolithic, vertical, SOA, and micro‑service architectures, emphasizing that the current system is a traditional, non‑separated front‑back end monolith.

Observed Online Issues

CPU spikes during flash‑sale periods.

High request counts per application server (over 3000).

Redis connection count around 600 ( connected_clients:600 ).

MySQL request timeouts.

Frequent Full GC (152 times in 24 h) and thread deadlocks.

Investigation Process

The investigation covered all servers (application, image, timer, Redis, DB), checking memory, CPU, request volume, and connection counts. Tools such as jstat -l pid and VisualVM were used to analyze JVM behavior.

Root‑Cause Analysis

Excessive request volume during flash‑sale caused server overload.

Redis connection pool exhaustion.

JDBC connection pool exhaustion.

Large‑object allocations leading to frequent Full GC.

Improper Tomcat, JVM, Jedis, and JDBC configuration.

Lack of traffic shaping, rate limiting, and isolation of the flash‑sale module.

Resources (Redis, JDBC) not released promptly.

Final Solutions

Increase application servers and implement traffic shaping/flow splitting.

Optimize JVM parameters. Example configuration: 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"

Adjust Tomcat concurrency settings (switch BIO to NIO2, tune thread pools, connection limits).

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

Code refactoring: remove large objects, ensure timely release of connections and other resources.

Increase cache size in conf/context.xml : <Resource cachingAllowed="true" cacheMaxSize="102400"/>

Result

After several days of observation, the system remained stable. Monitoring screenshots show reduced CPU/memory usage, fewer GC events, and normal request throughput.

Conclusion

While the immediate issues were resolved, the monolithic architecture still poses long‑term risks such as tight front‑back coupling, lack of isolation for flash‑sale traffic, no MQ‑based flow control, and non‑high‑availability Redis deployment. Future work should consider refactoring to a more modular or micro‑service architecture and implementing proper traffic shaping mechanisms.