From One Server to Millions of Users: Scaling an LNMP Stack Step by Step

Single Machine

A small site with less than 100 daily UV runs on a single 1‑core, 1 GB RAM CentOS machine hosting Nginx, PHP‑FPM and MySQL.

Two Machines

When daily UV exceeds 5,000, a second server is added to run MySQL separately, while the original machine handles Nginx and PHP‑FPM. Compiling the LNMP stack across machines requires installing MySQL on the web server even if PHP does not need it.

Add memcached

With UV reaching ten‑thousands, a memcached service is added to the web server to offload the database, and the PHP‑memcache extension is installed.

Add Web Server and MySQL Master‑Slave

When UV reaches 50,000, a second web server is added and a MySQL slave is introduced for backup. DNS round‑robin distributes traffic, but this introduces a single‑point failure if one web node goes down. Shared storage via NFS is used to keep uploaded files consistent across web nodes, and each web server runs its own memcached instance.

MySQL Read‑Write Separation

With daily UV climbing to hundreds of thousands, slow queries appear. Two solutions are presented: modify application code to direct writes to the master and reads to the slave, or use mysql‑proxy to achieve the same without code changes.

Load Balancing

After a failure of an older web server, a load balancer (Nginx) is deployed in front of the web nodes to provide high availability. Nginx is chosen for its simplicity over LVS or HAProxy. MySQL‑proxy remains on the same server to avoid another single point of failure, and the NFS server is noted as a potential risk.

Further Expansion

When UV reaches one million, a third web server is added and the NFS service is split into a dedicated server with a backup.

Introduce NoSQL

At nearly ten million UV, five web servers are required and MySQL begins to show pressure from specific heavy queries. The solution is to offload hot data to Redis, with Redis configured in master‑slave mode to avoid a single point of failure.

MySQL Architecture Evolution

Assuming a Discuz site grows from a tiny traffic to tens of millions of daily PV, the MySQL architecture evolves through several stages:

Stage 1: PV < 10k – single machine runs both web and DB; optional master‑slave for safety.

Stage 2: PV 10k‑50k – separate web and DB servers; introduce memcached; optional master‑slave.

Stage 3: PV 50k‑100k – higher‑spec machines; consider MySQL clustering; one master with multiple slaves for redundancy.

Stage 4: PV 100k‑1M – one‑master‑many‑slaves becomes bottleneck; restructure to a hierarchy where the primary master handles writes and a secondary master distributes bin‑logs to many downstream slaves.

Stage 5: PV > 1M – write load dominates; split databases by business modules (users, permissions, points) and perform sharding/partitioning; possibly separate hot tables onto dedicated servers.

Conclusion

Further growth continues with table partitioning and sharding, as exemplified by large e‑commerce platforms that partition MySQL databases by region, buyer/seller, or time dimensions.