Kernl had another great month, with some bug fixes, blog entries, and a few new features.
Most importantly we’re announcing a limited beta of our new global update CDN! With our new global CDN powered by Vercel, every Kernl update request is cached at edge nodes around the world. This means <= 50ms response times for updates globally.
Reach out to email@example.com if you’d like to give it a try!
Features, Bugs, and Performance
Docs – Added more descriptions to the “Understanding Graphs” portion of the Kernl documentation.
Analytics Date Selection – The flow for selecting dates and products in analytics has changed. You can now only select dates in the range that the selected product has data.
Examples – The Kernl API Examples repo has been updated to include a license management example.
WHMCS License Validation – Kernl now supports WHMCS license validation for plugins and themes. This integration works similarly to our other 3rd party license validation integrations.
Performance – We added a few database indexes to our load testing database. In situations where a lot of load tests existed performance was abysmal.
Tutorial – On the main dashboard page of Kernl there is now video tutorials for getting started with plugin and/or theme updates.
License Expiration Date Bug – There was a bug in Kernl license management where date editing didn’t work correctly when the saved date started with a leading zero.
License Domain Restriction Bug – An edge case existed where license validation would fail with a server error if domain restrictions are set but no domain was passed in to be validated.
Download Increment Bug – Incrementing download count was being handled in a very naive way. It was originally developed when Kernl wasn’t expected to reach the scale it has. This has been resolved by using the $inc operator in MongoDB instead of a find -> increment -> upsert.
Load Test Infrastructure Bar – The progress bar when you create a load test didn’t have a very good default state (it looked like nothing was happening). Now when below 3% complete, the bar will show 3% so you can actually see that things are progressing.
Site Health Edit – You can now edit your site health entries.
Envato License Validation Bug – Due to the deprecation of an API endpoint we were using, users of our Envato license validation need to regenerate their Envato access token that is saved with Kernl.
Envato License Tied to ID – You can now verify that an Envato license that is being used is tied to a specific plugin or theme.
For a few years now the DigitalOcean Marketplace WordPress image has been available for installation on their droplets. If you want to use WordPress but don’t want to go through the trouble of configuring it, this is a great place to get started.
Ease of Installation
The DigitalOcean Marketplace WordPress image installation isn’t one click, but it is easy. It takes a few steps, including:
Sign up for DigitalOcean or log in.
Click “Create” then “Droplet”.
Select the image
Pick your droplet size
Select your region for deployment
Add your SSH Keys (optional)
Name your VM
Create the droplet
Overall, the UX for creating the droplet with the WordPress image installed on it is super easy to follow. DigitalOcean has done a great job removing friction from the process.
Compared the to Vultr One-Click WordPress installation the DigitalOcean image has less included out of the box, but this isn’t necessarily a bad thing. The DigitalOcean marketplace WordPress image is configured with the following software:
Ubuntu 18.04 LTS
Most of this is fairly self-explanatory with the exception of Fail2ban and Certbot. Fail2ban scans Apache logs for malicious patterns and bans those IP addresses. Certbot provides free SSL certificates for your site.
In addition to installing the packages above, the DigitalOcean Marketplace WordPress makes some common sense security changes to help keep you secure.
Enables UFW firewall to allow SSH, HTTP, and HTTPS.
Sets the MySQL root password and runs mysql_secure_installation.
Creates an initial WordPress config file and sets up the salt keys.
Disables XML-RPC to prevent DDOS and brute force attacks.
Modifies PHP settings to increase max file size and execution time.
Enables Apache rewrite module for WordPress permalinks
For the vast majority of WordPress sites, this will be plenty of power for you.
DigitalOcean Marketplace WordPress Performance
So you’ve installed this WordPress image from the DigitalOcean Marketplace and you want to see what kind of punishment it can take. Cool. Kernl’s got your back.
The requests per second performance of the baseline image isn’t terrible, but it isn’t great either. Right around 14 requests/s the wheels fall off and error rates spike. Eventually the application failed to response to any requests.
You can see the response time average and median stay right around 150ms until the server becomes overwhelmed. The numbers here are misleading though because this chart only takes in to account successful requests.
The final chart is the response time distribution. Of all requests, 50% finished in under 500ms. 100% finished in 5000ms. The 5000ms mark is interesting because that’s the timeout that was configured by DigitalOcean on the WordPress image. Just because requests finished, doesn’t mean they were successful.
DigitalOcean Marketplace WordPress Performance with Caching
Most people run some sort of caching with their WordPress site. For this test we used W3 Total Cache with all caching features enabled.
You can see that the throughput of the site increased quite a lot once caching was enabled. Failures didn’t start to see and uptick until around 60 requests/s and then stayed relatively consistent at around 10 failures/s with requests leveling out at 130 req/s. To be clear, 130 req/s is a lot of traffic.
The average response time leveled off at around 110ms, with the median coming in at around 80ms. The difference between the two is interesting because it means we had some pretty big outliers.
The response time distribution gives an interesting take on the average/median response time graph. We can see that 99% of our requests finished in under 250ms, but that last 1% took up to 9000ms. That explains the difference between the median and the average.
In general the performance of the $5 droplet with the DigitalOcean Marketplace WordPress image on it was acceptable. Once caching was enabled it became quite good. The best part about this image is that it takes care of basic security things for you and doesn’t try to guess what you want.
In short, give this image a try. It might save you some time.
If you want to host your own copy of WordPress but don’t want to go through all the trouble of setting it up, it might be worth your time to explore using “one-click” installs from some of the major cloud providers. In this article, we’re going to explore the Vultr One-Click WordPress install and see what it’s all about.
Ease of Installation
Before anything else you need to get a WordPress box spun up on Vultr. Overall, the experience was pretty easy:
Click the “Application” tab and then select WordPress.
Select your server size (25GB SSD $5/month for this test)
Add your SSH key
Fill out your host name
Click “Deploy Now”
So obviously this isn’t a single click to install, but it is a lot easier than setting up and configuring a WordPress installation from scratch.
Aside from the obvious stuff (WordPress, MySQL, etc) which we’ll cover in the next section, what else is included with your One-Click Vultr WordPress installation?
XHProf – XHProf is a tool for profiling PHP applications. This could be very helpful if you find your site getting real slow after installing a plugin or theme. It could help you determine the source of the slowness.
PHPMyAdmin – The classic MySQL database administration tool for the web. If you haven’t used it before, its a great way to browse your database and make changes.
Maldet – Maldet is a Linux malware detection tool that runs periodically on your system to see if it has been infected. This is disabled by default, but can easily be enabled with the directions included with your new server.
Cockpit – Cockpit is a web based interface for your server. You can easily see how your server is configured, what resource usage looks like, and update packages all without even SSHing into your server.
What’s WordPress Running On?
The Vultr One-Click WordPress system that we decided to use had the following hardware and software:
Ubuntu 18.04 LTS
Overall the software is a pretty standard LEMP setup and the hardware is as performant as you would expect for $5 per month. It’s also worth noting that the installation script for this one click install might need some updating because it installs the previous version of WordPress.
Performance Out of the Box
So you’ve spun up your new Vultr One-Click WordPress server, but what sort of performance can you get out of it? Using Kernl’s WordPress Load Testing we can easily see the performance that this $5 per month server gives you.
For both this test and the cached test (next section) we attempted to have 200 concurrent users browse the WordPress site for 30 minutes. The traffic was generated from Digital Ocean’s NYC3 datacenter.
As you can see we get up to about 20 requests per second before the server starts returning failures. For a $5 machine this isn’t bad at all. 20 req/s over the course of 24 hours is ~1.7 million requests.
Initially response times are pretty good, but as resource contention on the server increases the average and median response times start to go up. Even when under full load, the pages returned in under 5 seconds. Not terrible, but you definitely aren’t winning friends with that sort of performance.
The response time distribution is mostly what you would expect after seeing the error rate and the average response time. 99% of requests return in under 5.5 seconds. In general you want to see your 99th and 100th percentiles be low, but given the duress the server was under this isn’t surprising at all.
Overall the system performed well and was configured well enough to handle a small-ish load test.
Performance with Caching
The test above is almost silly in that most people willdefinitelybe using some form of caching on their WordPress site. For a more realistic test, I enabled W3 Total Cache on the WordPress installation. There wasn’t any Memcached or Redis installation available, so all cache settings were tuned to “Disk (enhanced)”.
As you can see the difference in performance with caching enabled is quite good. We didn’t see any errors at all for the duration of the test and the maximum concurrent requests per second peaked at 160. Over a 24 hour period, that would be 13.8 million requests.
The response time over the course of the test was also quite good. Initially it hovered around 35ms on average, but as resource contention on the server increased it leveled out at around 140ms. Not too bad for $5 and nearly zero configuration.
Finally we come to the response time distribution. You can see here that 50% of requests finished in under 100ms, 99% finished in under 700ms, and all requests finished by 1800ms. These are good numbers.
If you need to host a WordPress site and don’t want to much around with configuration, the Vultr One-Click WordPress service is pretty good. In the long-term you’ll still need to know a little about system administration to apply updates, but it is definitely a great place to start and gets you a lot of the way to a fully functioning WordPress site.