Category: Tech

Hey guys, below is a tutorial on how to speed up your WordPress installation in the Cloud. This tutorial will cover an installation of WordPress on a Linux LAMP stack on a instance on the AWS Cloud inside Ec2.

First things first, depending on your instance size and specs you will need to run some calculations on how much your server can actually take. Most users miss an important step with their default Apache installation on their server or instance in the cloud. The biggest misunderstanding is that Apache will work out of the box perfectly with any server size. This is wrong. The default Apache settings require quite a bit of server resources and if you do not have them, which you won’t likely will not. This calculation uses your available ram to calculate Apache’s prefork MPM settings. The calculation out something like this: (Total Memory – Critical Services Memory) / Size Per Apache proces.

The idea of making this calculation is to ensure that Apache leaves enough memory for your system to use and not starve other processes such as MySQL.

From httpd.conf:

prefork MPM

StartServers: number of server processes to start

MinSpareServers: minimum number of server processes which are kept spare

MaxSpareServers: maximum number of server processes which are kept spare

ServerLimit: maximum value for MaxClients for the lifetime of the server

MaxClients: maximum number of server processes allowed to start

MaxRequestsPerChild: maximum number of requests a server process serves

Now the best way to tweak this is to understand how much each Apache process is using currently and take that number into consideration. For example if you have the following configuration:

For example the above configuration would keep at a minimum 10 processes running at any given time (Start Servers) which you also only allow a max of 10 to serve your clients (Max Clients). In this case MinSpareServers and MaxSpareServers should not come into play. After a single process serves 4000 requests it will be terminated and another called to replace it based on the MaxRequestsPerChild directive.

So assume that you have 1.7GB of memory to work with which is in line with an m1.small instance on Ec2. So lets say that you have 60MB per process average httpd. Assuming 200MB for O/S and other services (more if running MySQL), you have 1.5GB – lets leave about 10% spare which would give you about 23 processes max. So lets try:

These optimizations are necessary if you want to have a smooth running server and to endure a large traffic spike. I also suggest taking a look at MySQL optimization if you are running a local SQL server and not remote like RDS. I do not have specific steps detailed here but I have provided a resource to take a look at.

Next I would like to take a look at empowering WordPress to use a CDN in the cloud like AWS CloudFront or any other service you choose. For the purposes of this tutorial I used CloudFront. We can do this with a WordPress Plugin called W3 Total Cache. Go ahead and install this plugin onto your WordPress installation and take a look at the CDN options. To setup your W3 Total Cache plugin to use CloudFront, select “Performance” then “General Settings,” then scroll down to CDN, then check the enable box and switch the drop down menu to Amazon CloudFront under Origin Pull. Then press save. Once saved go to “Performance” then “CDN” and add your AWS Access Key and Secret key which can be found here.

You can either press “Create Distribution” from the plugin to create your CloudFront Distribution or you can do it manually via the AWS Console. Please be patient, your CloudFront distribution will take anywhere from 15-30 minutes to create on AWS. Once finished you can save and test your settings. You should then see your code change when you view source in any browser to include your custom cname or the distribution ID.

Now I do recommend that you use CNAMEs, and at least 2-3 of them because this will speed up page load time by giving your browser different CNAMES to point at and open up parallel download threads that will increase overall page rendering time.

Now using a CDN is only the first step, there are many other options in the plugin to increase speed. You should also enable the Page Cache options, database caching, and minify. Please read about each option in the support tab of W3 Total Cache here “domain.com/wp-admin/admin.php?page=w3tc_faq.” I may add to this tutorial in the future but this should give you a head start. Also remember to test your performance with Pingdom afterwards.

This guide applies to increasing the root volume size of an EBS EC2 Linux instance on AWS. By default most Linux instances come with an 8gb root volume unless you changed it at first launch. If you are one of the people that forgot to do this or you just simply need to extend the volume take a look at this guide. Be sure to also check out my other guide on how to increase the size of a Windows EBS Volume.

I started out with an Amazon Linux instance and an 8gb volume. First you want to navigate to your AWS Console and then click EC2 and then Volumes on the left panel. Find the volume that your instance is attached to and right click and create snapshot.

A new window will pop up and you can fill in a name and description and then select ‘Yes, Create’.

Once your snapshot is started creating, navigate over to the snapshot section of the EC2 Console on the left side panel. You will then look for the snapshot you just created with the same name you gave it. This may take a while to for the snapshot process to complete.

Once the snapshot is complete, right click on the snapshot and select ‘Create Volume’. Now pay attention here because this is where you specify the new volume size which is larger than previously, for this example I chose 100gb. Please also note that you need to make the volume in the same Availability Zone as your instance, mine happens to be in us-west-2a. You must also choose either a standard volume or Provisioned IOPS. Once done, press ‘Yes, Create’.

Once the volume is created, navigate over to your EC2 Instances section and go ahead and stop your instance. Once stopped, go ahead and detach the original root volume from the Volumes section of the EC2 Console. To do this you simply find the volume attached to your instance and right click, and select detach.

Once the volume is detached, go ahead and attach the volume you created to the instance by selecting the 100gb volume, right click, and attach the volume to your instance specifying the mount point as /dev/sda1.

You may now start your instance again. Once your instance is back and running go ahead and SSH into the instance (Note: Your IP address may have changed or you may need to re-associate your elastic IP address). You may also need to switch to root if logged in as ec2-user, use ‘sudo -s’ to accomplish this. Now the attached volume will still appear as 8gb until you extend the volume with ‘resize2fs /dev/xvda1’ as seen in the code below. Your mount points may vary, you can check these with either ‘mount’ or ‘fdisk -l’.

If you have ever wondered how to use the Amazon SES SMTP endpoint with Postfix this is the guide for you. This is going to be very close to what is in the documentation on the AWS Website. I will cover some pain points that I have seen and ran into while trying to implement this.

Below we will cover integration to SES with both STARTTLS and Secure Tunnel (STUNNEL).

To configure integration using STARTTLS

1. On your mail server, open the main.cf file. Depending on your OS, this file resides in the /etc/postfix folder.
2. Add the following lines to the main.cf file, modifying them to reflect your particular situation, and then save the file.

3. Edit the /etc/postfix/sasl_passwd file. If the file does not exist, create it. Add the following lines to the file, replacing USERNAME and PASSWORD with your SMTP user name and password. Now this is where it gets confusing, you will want to create a SMTP User from the SES Console at: https://console.aws.amazon.com/ses/home?#smtp-settings. You will create a user here and be presented with the following Window not from the IAM Console as the credentials are different:

Please NOTE: These credentials are an example and are now invalid, please do not use them.

To begin, you will need to set up a secure tunnel as described in Secure Tunnel. In the following procedure, we use port 2525 as your stunnel port. If you are using a different port, modify the settings that you actually use accordingly.

1. On your mail server, open the main.cf file. On many systems, this file resides in the /etc/postfix folder.

2. Add the following lines to the main.cf file, modifying them to reflect your particular situation, and then save the file.

Now you also need to make sure that you correctly flag the from address and setup your mail server correctly with a verified domain otherwise you will get the error Email Address not verified. Also if you do not get the credentials right above you will end up with the following error: “Apr 16 05:26:33 domU-12-31-39-16-38-A6 postfix/smtp[1101]: CE19B421CD: SASL authentication failed; server email-smtp.us-east-1.amazonaws.com[50.19.243.

215] said: 535 Authentication Credentials Invalid”

If you’ve gotten this far without errors then I believe you are set! Let me know if you have any trouble with this guide and I will try and make any section clearer