One of the simplest ways to ensure WordPress speed grandeur is to focus on the things that can clog down your web server: media files. Every page has loads of them. Images, videos and too many stupid GIFs. I know, I know – who am I to talk. But let’s face it: text is not the most satisfying content out there any more. But what to do if you already have exhausted all the common strategies of improving performance – such as using proper caching or optimising all images?

Offloading media to the rescue!

Offloading media means to save your images not only in the „/wp-content/uploads/“ folder – a.k.a. your web server – but also on a specialised service providing you with cheap storage and fast delivery – a Content Delivery Network or CDN for short.

But why – in the name of Tim Berners-Lee – would I waste any more of my hard-earned golden nuggets on hosting?

Anyone hosting websites on the cheap

Good that you ask. Because first and foremost your users will thank you for improved speed and better user experience – and Google will rank you better. If that alone does not tickle your buttons, then listen to this:

Spending money on offloading media and a proper CDN setup will actually save you some bucks as you scale up.

Lonely Austrian Nerd

Spending money to save money? No, I am not entirely crazy. Let me explain.

Let’s say you host the Website of a medium sized company aiming for signups to a service – and assume that you regularly send out newsletters which lead to spikes in visitors. These spikes turn your website sluggish – the reason why your conversions are down 25% in comparison to any normal day. That sucks, mate.

So how do we fix this?

Well, doubling server resources would most certainly take care of things. But it seems crazy to basically double server costs just to handle one spike every couple of months. Going static rocks hard when it comes to performance – but would also require a full rewrite of the Website.

I say let’s get rid of media. But not by getting rid of the images itself but rather offloading them to a CDN. For this Proof-of-Concept I ran a WordPress Multisite installation on a basic tier droplet of DigitalOcean ($5/month) using a managed database (MySQL, $15/month) – using flood.io to load test three pages with multiple images and 100 concurrent users – resulting in thousands of requests per minute.

Initial run without offloading media

I hear you say „are you barking mad? 100 concurrent users on a tiny droplet like that?„. Well – if caching is used (in this test I use the W3 Total Cache plugin), this fares relatively well:

So, what do we have here? As you can see by the lack of red, the rate of failed requests was actually 0 – so no failed requests at all. That’s good. However, what becomes painfully obvious is the influence of concurrency on response time – after the ramp up period the perfectly acceptable 250ms jump up to a „I-will-bounce-from-this-site“ 8500ms; a bloody disgrace to any professional Website. All in all, this should not come as a surprise – using a $5/month server to be bombarded with almost 2,500,000 requests a day (approx. 1,760 requests per minute) seems to go a bit overboard

Performance of WordPress with media offloading to a CDN

New the moment of truth: how does WordPress fare when offloading all media to a CDN? Well, great. But before diving into the data let me explain what exactly I offloaded – so that you can judge the possible impact offloading media to a CDN can have for your WordPress installation.

First of all, I used DigitalOcean’s „Spaces Object Storage“ with a custom subdomain to offload media from my server. The process of uploading all media automatically to this object storage is done – quite unusually – not by plugin, but by using a combination of Lsyncd and s3cmd. But let’s not get distracted by the more exciting parts of this PoC and get back to the boring data – a post will follow on how to build a similar setup.

Same testing period, same ramp-up period – and most important of all, same amount of concurrent users. As you can see in the comparison above, the results are quite striking. Not only was the test able to run at a substantially higher transaction rate of 2,250 requests per minute – an increase of well over 25% – but also the response times decreased mindbogglingly: from a catastrophic 4.7 seconds to an average of 166ms. I cannot stress this improvement enough: while serving approximately 3,240,000 requests a day the response time decreased to an average of 3,5% of the initial reaction time – all at the negligible cost increase of $5/month.

How far can we push this?

So, now we have seen a direct comparison of WordPress running on a small server without and with CDN. We saw that offloading media to a CDN yields substantial benefits to anyone trying to squeeze out every inch of performance from good ol‘ WordPress.

Well – to be perfectly honest, this has nothing to do with WordPress itself. The reason why this works so well is simple: by offloading media to a managed service hosted somewhere else, there is no need for our server to flex its muscles. As the images are not loaded from the same host as WordPress, the web server (Apache in this case) does not have to work as hard due to fewer requests made (about half actually – but this greatly depends on your site/workload). Consequentially, with less requests the CPU does not need to work as hard, the memory does not fill up as quickly and the drives hum along softly as there are very few files to serve.

This is all great. But when are we finally going to break things?
Patience, young coder.

Alright – how far can we push this? Let’s give this another run – and triple the number of concurrent users to 300.

While it still amazes me that this setup can handle over 6.2 million requests per day without returning a single error, one thing becomes clear: with an average response time of almost 10 seconds we won’t be winning any medals from our customers. Nevertheless, this PoC strengthens my view that scaling WordPress is not only a matter of pushing more money to a better hosting provider but substantially depends on your ability to optimise.

Summa summarum

In this post we used Object Storage to offload our WordPress media. This enabled us to more than double the amount of concurrent users our server can handle – and still leaves some room for further optimisation, such as offloading CSS and JavaScript files, offloading minified files generated by T3 Total Cache, switching from Apache to nginx, …

Your Website experiences spikes and you want to save a buck while still being able to handle more users? Go ahead and use a CDN – your visitors will thank you with higher sign-up rates.

How do you optimise your WordPress installations?

The post Performance gains from offloading WordPress Media to S3 / DigitalOcean Spaces appeared first on jiaa.io Blog.

However, as peace of mind prevails, I tend to upgrade once the main upgrading related issues have been sorted out – or at least have been discussed in the community forums. For me the sweet spot to jump on a new release is around 2-3 months after its roll out. If you have to support something mission critical, this might take a bit longer.

Be that as it may, let’s get Ubuntu 16.04 upgraded to Ubuntu 18.04 on DigitalOcean ?.

Step 1: Snapshots, Snapshots, Snapshots

It seems redundant to write this – but it’s unfortunately still common practice to just wing it when upgrading a system. But it should go without saying that losing all of your data is a bit more than potentially problematic. As I run all of my infrastructure on virtual servers (Droplets) provided by DigitalOcean, it’s very easy to not only back-up all of my data, but to make a functional snapshot of the full machine.

If you want to take a snapshot of your droplet, you simply go to the droplet in question, select „Snapshots“ in the sidebar menu and click the „Take live snapshot“ button – and wait for it to finish.

It’s good practice to shutdown the droplet before doing so as well as ensuring that the snapshot actually works, so you don’t have any surprises if something does go wrong…

Step 2: Installing updates

Let’s start with the fun part: installing stuff. Hop onto your machine with the nice SSH access of yours.

$ ssh user@1.2.3.4

I hope for you, that you have a nice SSH key already installed so you don’t waste precious time thinking about your password.

Update already:

$ sudo apt update
$ sudo apt upgrade
$ sudo apt full-upgrade

I know, I know – the last one might be redundant. Sue me ?

Step 3: Upgrading to that hot new version

And here we are, finally ready to upgrade to Ubuntu 18.04.

$ sudo do-release-upgrade

You will be asked some questions before the upgrading process starts. Just hop along with ‚y‘ and everything will be fine (hopefully^^). A healthy dose of reading the output and thinking about what it means will do the trick. Just be aware that this might take a while. You’ll also be prompted with a SSH config step – as I have modified my sshd_config I will stick to my current one.

After some time your happy little machine should be telling you that the upgrade is complete – otherwise you will have encountered some error. As this requires a restart, continue with ‚y‘.

After accepting this, you will be disconnected. Give your machine a couple of seconds to reboot and reconnect.

And there we go – 18.04 LTS (XenialXerus) runs smoothly, including all services that were hosted on the machine before upgrading. For peace of heart, it’s not unreasonable to check ones firewall, so that just the needed ports are open to the public.

And that’s that ????

The post Upgrading Ubuntu 16.04 LTS to Ubuntu 18.04 LTS on DigitalOcean appeared first on jiaa.io Blog.

This. Happens. Every. Single. Time. 

So I started learning from data. As misleading data driven design can be, it gives one a heck of a fast start. That’s why I analyse my personal pages as well – I want to make them better by improving gradually. But which tool should I use?  On first sight services such as Google Analytics seem like a great deal: easy to implement, easy to use as well as extensive – and above all „free„. But it does come at a heavy price – your users privacy.

Open source to the rescue!

Piwik is an open source analytics platform you can host yourself. You have full ownership & control over the collected data; so no snooping around from corporations at least. For this tutorial I chose DigitalOcean as the host – a cloud infrastructure provider where I have most of my virtual machines.

Step 1: Starting a droplet

Choosing the right droplet for this project almost couldn’t be simpler: the host operating system of this machine is going to be Ubuntu 16.04, with the smallest size available. 512mb of RAM might not be enough for a lot of sites, but as this is only a test it’s plenty. I also like to have things around Europe – so I chose Frankfurt, Germany as the datacenter region. Don’t overlook that „One-click apps“ tab on top – there’s a lot of open source awesomeness in there! In order to save us some server setup hassle, I went for the „LAMP 16.04“ image provided by DigitalOcean. It comes with a properly set up firewall and some security best-practices per default – kudos to that DigitalOcean! Hitting the „create“ button will do everything we need.

Step 2: Server Setup

So the droplet is up and running – let’s give it a purpose. First you’ll want to log into the machine. Being a terminal kind of guy I’ll do just that – but you can use PuTTY or anything else as well if you want to.

ssh root@YOUR_IP_ADDRESS

If you have set up your droplet without a SSH key, then you have an email with the login credentials in your inbox. But be aware: using SSH keys to login on servers is way more convenient and secure. DigitalOcean has a nice tutorial to do that. After login you’ll be greeted with a lot of info:

The first thing to do is to update the system:

apt update

and

apt upgrade

will do the trick. But only keeping the system up to date will not help you being reasonably secure – follow this tutorial to secure your droplet right from the beginning. Especially changing to a non-root user is a smart move.

You’re doing great so far

Step 3: Setting up Let’s Encrypt certificates

I did a lot of complaining in my last post, that shöpping.at – the new online market for Austrian goods – hasn’t set up SSL certificates properly (they have now). So here’s a quick one how to do so. Because Digital Ocean droplets with LAMP come with everything needed pre-installed, it’s as simple as:

sudo letsencrypt --apache -d yourdomain.org

To renew your certificate you simply do:

sudo letsencrypt renew

To set up auto-renewal you can follow this tutorial.

Step 4: Setting up PIWIK

In order to install PIWIK on our Ubuntu 16.04 droplet, we have to change to the www folder:
cd /var/www

There we download the latest PIWIK build and unzip afterwards:
wget https://builds.piwik.org/latest.zip
unzip latest.zip

Then we transfer all files from the PIWIK folder to the html folder and setup the rights properly:
mv piwik/. html/
chown -R www-data:www-data /var/www/html

If you hit the IP of your server in your browser you should get this.

Well, the first battle seems to be won! So let’s configure it. Hit the next button.

And there it is – a missing PHP extension appeared! Almost as easy as catching a Pokèmon this error can be fixed:

sudo apt install php7.0-mbstring

Take that, Magikarp of PHP. 

Step 4: Setting up a database

The next step leads us to the database credentials. If you read the server login message carefully, you know the password of the MySQL root-User can be found with:
nano /root/.digitalocean_password

So we have the database server (127.0.0.1), the username (root) and the password. But we lack the database name, because we haven’t set up a database so far. So let’s do just that:
mysql -u root -p
CREATE DATABASE databaseName;

We’re almost there.

Enter your data in the database form in your browser and hit the next button. After a success-message telling you your tables were created, hit next again. Then you can add a super admin user – be smart and add a safe password!

Just a little further – enter some details about the website you want to start to analyse and hit next. Then you’ll be provided with the code that needs to be included on all sites of your website. If you user a CMS such as WordPress, you can use a plugin to achieve that.

And there you go:

Now, wasn’t that easy? 

As enjoyable as this his been, you’re not done yet. Learn how the thing works, secure your server properly and give hands up to the guys over at PIWIK and Let’s Encrypt for providing you with all of this for free!

Image from stocksnap.io, CC0 License.

The post How To Install Piwik on an Ubuntu 16.04 Cloud Server (DigitalOcean) appeared first on jiaa.io Blog.