Building a server platform for a busy WordPress blog

TheLincolnite is one of the fastest growing regional news websites around. They’ve won numerous awards for their refreshing approach to up-to-date journalism, and in the 18 months they have been a customer with Jolt, they’ve grown from around 50,000 monthly page views to well over 1 million. That’s impressive!

As well as impressive, it has also posed a set of infrastructure challenges as TheLincolnite outgrew their old dedicated server.

We were asked to step in and upgrade their single dedicated server to a platform that can potentially sustain up to 5M page views per month. Our years of WordPress hosting experienced went to work, and we quickly drew up a blueprint for a solid server platform to handle their growth.

There were several challenges here:

  • To provide database server load tolerance. The Database Server is the weakest point of any heavily loaded site, the least scalable. In turn, the weakest point of any database server is storage system performance, DB transactions are extremely I/O intense.
  • To provide sufficient computing power for WordPress code execution. WordPress is known to be CPU intense, and caching, which is supposed to improve WordPress site speed, often makes things even worse due to high I/O demand.
  • To provide future scalability path for the hosting platform.

 

Our solution was to separate the Database Server from web server physically. This removes shared I/O, affecting both database and web server performance in a single physical environment.

We selected the fastest, latest, most performant hardware base for both the Database Server and the Web Server. These have same hardware platform, which is dual-CPU Intel Xeon e5-2620. Recent series high grade CPUs provide enough processing power to sustain expected load, assuming there are no other bottlenecks on the platform.

The Web Server has 128GB of physical RAM, and its storage system is hardware RAID-10 on 4 x 1TB mechanical enterprise-class SATA drives. RAID-10 is our mainstream solution, it provides very good access speed even in case of array degrade, and has excellent level of redundancy. Large SATA drives in RAID-10 array were used as a tradeoff between access speed and storage capacity.

The Web Server requires quite a lot of space for content uploads and extensive logging, however, there’s no extreme IOPS rate here, unless swap space is heavily used. The latter would hardly be the case, as we have more than enough physical memory. We even have enough RAM for deploying memcache for SQL query results in future, in order to leverage MySQL load. At this stage and level of load, RAM-based memcache isn’t required – the hardware has a lot of spare overheard.

The Database Server has less RAM at 64GB. Physical RAM is important but over a certain level, it isn’t the most critical resource for MySQL database, unless you store full data replicas in memory (we do not). A more common bottleneck of database servers is storage system performance, and not linear data transfer speed, but rather response time. That’s why selected RAID-10 array, built on 4 x SSD drives here. This may sound an overkill, but it’s not. A Database rule is: “storage is always slow”. Further, we used extra RAM for database temporary space. Temporary tables are created and destroyed very intensively during normal database operation, which means file creation and deletion, so this has serious impact on storage system load. /dev/shm did the trick here.

Filesystem configuration on DB server:

FS_config

Database filesystem config

MySQL configuration for temporary space on virtual FS:

my_cnf

MySQL temporary FS configuration

Live mounts:

mounts

Live mounts

Actual storage space usage:

FS_usage

Actual disk usage in production

If we ever need to scale up even further, there are several tiered options:

  • When PHP performance becomes the bottleneck on web server, we will add PHP caching and caching NGINX instance in front of apache.
  • If we need to scale PHP engine even further, separate MySQL server would let us add more web servers to the platform, and put them behind a load balancer.

When database performance becomes a bottleneck, we add memcached to web server(s), which dramatically leverages MySQL load.

Got a very busy / popular WordPress blog that requires powerful hosting? Have previous WordPress hosts been unable to cope with the load? Talk to us, we can help.