Spotting and Solving Backend Bottlenecks: Nginx, Tomcat, Redis, MySQL

Analyzing system performance bottlenecks is not simple; it requires a separate analysis for each system design. A complete, usable system includes a UI and is divided into front‑end and back‑end modules. The author focuses on the back‑end.

Typical Architecture

The analysis uses a common stack: Nginx + Tomcat + Redis + MySQL.

Request Entry – Bandwidth Factor

If 200 MB of traffic arrives simultaneously but the bandwidth is only 1 MB, merely receiving the data would take about 200 seconds. Bandwidth is the total amount of data transferred within a given time, and calculations differ between LAN and WAN.

Server ulimit Settings

On CentOS servers, the maximum number of open files and user processes can be checked and adjusted via ulimit and the /etc/security/limits.conf file.

# ulimit -a | grep open
open files                      (-n) 1000

# ulimit -a | grep user
max user processes              (-u) 7284

Kernel TCP Parameters

Commonly adjusted parameters in /etc/sysctl.conf include:

net.ipv4.tcp_syncookies = 0
# Disable SYN flood protection for high‑concurrency systems
net.ipv4.tcp_max_syn_backlog
# Increase SYN queue size
net.ipv4.tcp_tw_recycle
# Accelerate TIME_WAIT socket recycling
net.ipv4.tcp_tw_reuse
# Allow TIME_WAIT sockets to be reused
net.ipv4.tcp_max_tw_buckets
# Set total TIME_WAIT socket limit

These can also be modified directly via /proc/sys/net/ipv4:

cd /proc/sys/net/ipv4
echo "0" > tcp_syncookie

Nginx Core Parameters

Typical Nginx limits include maximum connections and per‑IP request limits:

# Limit each IP to 10 concurrent requests
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 10

Tomcat Analysis

Tomcat supports three connector modes:

BIO : blocking I/O, thread‑per‑request, lowest performance.

NIO : non‑blocking I/O (java.nio), default in Tomcat 8+, better concurrency.

APR : uses native OS async I/O via JNI, highest performance but requires native libraries.

Typical Tomcat connector configuration:

<Connector port="80" maxHttpHeaderSize="8192"
    maxThreads="4000" minSpareThreads="1000" maxSpareThreads="2000"
    enableLookups="false" redirectPort="8443" acceptCount="2000"
    connectionTimeout="20000" disableUploadTimeout="true" />

Key parameters:

maxThreads : maximum request‑handling threads.

minSpareThreads : threads created at startup.

maxSpareThreads : maximum idle threads.

connectionTimeout : socket timeout.

If 1,000 concurrent requests arrive but maxThreads is set to 500, requests will be queued, creating a bottleneck.

Redis Performance Bottlenecks

Large keys (e.g., a 50 MB list) cause network congestion when fully scanned.

Redis processes commands single‑threadedly, so heavy commands block others.

Running KEYS on a high‑QPS instance is dangerous; its O(N) complexity can stall the server.

Insufficient memory leads to system paralysis; set appropriate expirations and monitor data size.

MySQL Performance Bottlenecks

Relying solely on EXPLAIN without considering the overall context can miss issues.

Large tables (e.g., tens of millions of rows) may still be slow despite indexing; consider horizontal sharding.

Potential problems include table locks, unoptimized SQL, excessive result sets, inadequate hardware, and adaptive hash index lock contention.

Adaptive hash indexes can cause lock conflicts under heavy access; increasing partition count or disabling the feature can alleviate the issue.

Reference image for common EXPLAIN parameters: