Comprehensive Performance Tuning of a High‑Concurrency SSM E‑Commerce Application

Project overview: a single‑module e‑commerce system built on the SSM (Spring‑MVC, Spring, MyBatis) stack with a flash‑sale (秒杀) module deployed on a set of servers (F5 load balancer, three application servers, timer server, Redis, image server, MySQL master‑slave).

Observed problems during flash‑sale peaks: CPU on application servers surged to >3000 requests, Redis connection count ~600, JDBC timeouts, frequent Full GC (152 times in 24 h), thread pool exhaustion, and many threads requesting invalid resources.

Root‑cause analysis identified excessive request volume, saturated Redis and JDBC connection pools, large object allocations causing memory pressure, sub‑optimal JVM/Tomcat parameters, and lack of traffic shaping or isolation for the flash‑sale feature.

Solution steps:

Horizontal scaling – add more application instances and use hard‑load‑balancing to spread traffic.

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

Tomcat optimization – switch from BIO to NIO2 and adjust connector concurrency settings.

Redis and JDBC pool configuration – increase pool sizes and ensure timely release of connections.

Code refactoring – eliminate large object creation, release resources promptly, and reduce unnecessary object retention.

Cache tuning – enlarge <Resource cachingAllowed="true" cacheMaxSize="102400"/> in conf/context.xml .

After applying these measures, monitoring showed stable CPU and memory usage, reduced GC frequency, and the system remained stable during subsequent flash‑sale events.