For A Busy WordPress Website with Millions of Hits
WordPress is a great content management system to run your website. It's easy to use, and with little understanding and help, anyone can manage a website running on WordPress. Furthermore, you can deploy a WordPress website on any standard web hosting platform. But Deploying WordPress for Busy Enterprise Websites requires a little planning. There are two unique challenges that we need to address when Deploying WordPress for Busy Enterprise Websites:
Performance & Scalability
Cost Optimisation
How Do You Predict Traffic Patterns?
Unfortunately, there is no easy way to answer this question. You can not predict traffic busts. Let's take an example of a busy news website, one day, you have a world event that everyone wants to know about, and suddenly your website traffic ten folds or more for a few hours or a day.
Your second challenge is the resource waste caused by peak and off-peak traffic differences. You may get millions of visitors during peak, but you hardly get much during off-peak hours.
So, How Do You Scale Your Server to Manage Traffic Busts and Reduce Off-Peak Waste?
A standard approach to make your web server bigger and fatter can't help you in case of a sudden bust. Because to scale up your web server, you will need to shut it down. So, it causes downtime, and downtime is not good for business.
However, scaling up your server may address the second challenge, but you will have to scale to peak traffic size and hope your traffic peak stays consistent. However, by scaling up your server to peak traffic, you will be wasting heaps of resources during off-peak hours.
Let's see how we can address these challenges and cost optimise our setup.
We will use AWS Cloud in our example. However, you can achieve the same results on other cloud platforms.
Deploying WordPress to Auto Scale with Cost Optimisation
We will use the scaling out approach instead of scaling up. The difference is simple, instead of making your WordPress server bigger and fatter, we will add additional servers to help out—the key advantage is that you can scale without the need to shut down your web server.
A load balancer at the front of your servers will distribute traffic across multiple web servers instead of a single server. These servers can be in different locations to reduce the distance between your website and visitors. Or they can be in the same geographic area if your customer base is in a particular region.
Automate Scaling
Using Auto-Scaling, You Can Go to Sleep Without Worrying About Traffic Busts.
You can use AWS Auto Scaling to add and remove servers based on your setup conditions. For example, if your web servers hit 70% of utilisation, you can set the auto-scaling to add two more servers to the farm. Auto-scaling will automatically add two more web servers with WordPress running on them. The load balancer will know when these two nodes are online. The load balancer will distribute the traffic across the extra servers. Similarly, you can set up the conditions to remove the additional servers when the traffic is below a certain threshold.
Improve Redundancy
The scaling-out approach allows you to run your website on multiple servers. So you can set your WordPress site to run on two or more servers. Doing this means you are not at risk of downtime if your standalone web server fails.
Improve Performance
One of the best things about scaling out your WordPress website is the benefit of providing consistent performance at all times. Because of auto-scaling rules, you will never hit 100% server load, no matter how big the traffic bust is. Instead, your users will experience consistent performance.
Cost Optimise
We kind of already answer this in the auto-scaling section. Because auto-scaling is scaling out and in, it will optimise your cost. So when you have millions of visitors browsing your site, you may have hundreds of nodes servicing them, but during low traffic cycles, auto-scaling will shrink down your server farm to a bare minimum.
Setting Up WordPress Website to Scale-Out
Let's get a bit technical. Scaling up and down is easy, but scaling in and out requires a few changes in our deployment. The challenges we need to address are:
Decoupling Database
Decoupling Storage
A typical WordPress website has:
MySql Database
Image Library
Code
So when a WordPress website runs on a single server, all these things are stored on the same disk. So there is no need for synchronising databases and files across multiple servers. But running WordPress with scale-out requires the exact opposite.
If you log in to wp-admin and install a new plugin, one of the servers in the cluster services your actions. The new plugin files are downloaded and installed on that particular server. So how do the other servers get access to these new files? The same goes for the database changes. Let's decouple these issues.
Decoupling WordPress Database
The Database in WordPress stores pretty much all of the content except videos and images. We will use the RDS service on the AWS cloud to create a MySQL cluster. RDS is AWS managed database service, so don't worry if you don't have the skill set to run a MySQL cluster. AWS will take care of all the complexity. The only thing you need to do is to add your database to the RDS instance.
A typical RDS setup has two or more servers. RDS automatically synchronise information added to the primary database to secondary instances. If one of the database servers fails, your website will start using the secondary server, and AWS will automatically provision the replacement instant within minutes. All of your web servers will connect to the same RDS connection address, and you don't need to make any changes to your website connection in case of failure. The whole process is fully automated.
Decoupling Storage
Because you are using more than one web server to service visitors, it is critical for all of your WordPress servers to have the same files at all times. So, you must implement shared storage among the servers or synchronise their disks.
We strongly recommend using a single storage point for all servers. For example, we can use AWS EFS (Elastic File Storage) to store our WordPress files. EFS storage volume can be mounted to multiple web servers and service hundreds of nodes simultaneously. So, we can solve the storage issue by using a highly scalable and redundant network attached storage to a wp-content directory.
After setting up RDS and EFS, it does not matter which web server was serving the request to you when you installed the new plugin. All web servers will be able to see the new files and information added to the database.
You can deploy your WordPress website to service millions of requests per minute using AWS Cloud Technologies and this approach. In addition, you can refine your scaling strategy to only pay for the required capacity by the minute.
Ditch the Guessing Game, and Stop Fattening Your Server. Instead, move to iVersion Enterprise Web Hosting with a scalable, redundant, and cost optimise design today.
