Hosting WordPress problem for websites have huge traffic is always the difficult hassles of infrastructure for WordPress. Therefore in this article, I will guide you on how to scale up your website built by WordPress, with a large amount of traffic

Here is a picture I accidentally picked up somewhere but I don't remember 😹😹😹, it describes how to expand WordPress using some AWS services

Basically, there are many ways to have a good infrastructure for high-traffic WordPress websites. In this article, I will mention the way I know to help you in scaling WordPress Hosting for your website.

Infrastructure Hosting WordPress diagram

The picture below is an overview of the infrastructure used to scale WordPress. This way is a bit like the first image that I mentioned but has changed a bit to make it simpler and easier to understand.

Normally, I see a lot of people always set up Web Server, Database Server and Storage into one Sharing Hosting. When your website gains a large amount of traffic with a small server which handles all those services will lead your Server to overload.

So here the idea is that we will break down those Services into separate parts (divide and conquer) and use caching to solve the overload problem.

I will go through details and explain why I use each of those services and finally is the Flow of the diagram above.

Amazon CloudFront

Any resources like CSS, HTML or JS (static content) we will store it on Amazon CloudFront and this service will help us caching these resources to reduce load time whenever a user tries to send a request to the server. You can use the Assets Pull Addon Plugin to save these resources to Amazon CloudFront for your WordPress website.

Elastic Load Balancer

Our purpose is to have a system strong enough to load-bearing and scale-up, so here I will use 2 WordPress Instances to take turns for handling user requests. In order to navigate between of two instances, we will need a Load Balancer to handle this.

That's why I mentioned Elastic Load Balancer in this diagram.

Auto Scaling

As a useful service of AWS, in case if there are one of two WordPress Instance die, it will automatically create two new one and navigate user requests to them.

WordPress Instance

Here you can use AWS EC2 to install Nginx Web Server and put your WordPress source code into it.

Normally I will use Docker for setting up the environment (Nginx, FPM or Apache), then pull my WordPress source code from Github and put it inside
the container

S3 Bucket

Regarding images for WordPress website we will store it into AWS's S3 Bucket, especially websites with lots of images and saving it in the same place with web resources is not a good idea. Using S3 Bucket will make it easier for us to move our web resources and independent.

MariaDB Instance

Basically, WordPress uses MySQL as a database but you can use MariaDB instead because it will increase a little Performance.

Here I will try to separate DB Server into another Instance. The benefit of splitting the DB Server separately is ease of upgrade and management in the future.

Varnish Cache Instance

As I said caching will reduce load time for Web Server pretty much so we will have an additional Server Caching located between Load Balancer and WordPress Instance.

You can use Memcache instead of Varnish. But I recommend using Varnish because it is easy to config and also supports WordPress quite well.

Diagram Flow

When a user sends a request to the Server, CloudFront will check if it's the first time user go to the website, it will call the Server to get HTML, CSS, JS but if the user has ever visited the website it will return the Cache.

If the User is first logged in, it will ignore CloudFront and go straight to the Elastic Load Balancer and the Load Balancer will have the task of navigating to one of two WordPress instances.

Assume that there are 1000 users accessing at the same time, the Load Balancer will divide 500 users for the 1st WordPress Instance and the remaining users will call the 2nd WordPress Instance.

When a request is sent to the WordPress Instance, it will automatically check with the Varnish Cache Instance, if it is the first time it will execute the request itself or it will automatically retrieve the Cache from Varnish to return the User.

Whenever WordPress Instance executes it will call to S3 Bucket to retrieve the image rather than loading the image inside the Instance and will call MariaDB Instance to query the data as well.

WordPress Instance only performs the sole task of executing PHP Script, the image will be taken by S3 and the content will be in charge of MariaDB.

Advantages

• Reduce the workload by dividing All services by different Instance
• Easily upgrade and monitor the service
• Easily scale infrastructure
• Website has fast response
• Website has ability to reach large traffic
• Minimize the possibility of website collapse

Disadvantages

• More service, more cost
• Need to have basic knowledge about AWS to manage your infrastructure
• It takes a while to set up the infrastructure
• Will depend on AWS, it's difficult to move your infrastructure to another Service Provider

Conclusion

By reference diagram which I suggest above and apply it for your infrastructure will tackle the WordPress Hosting problem in case your website is increasing a lot of traffics every day. Besides that, increase maintainability and monitor for your website.