Your Australian Web Hosting SEO Checklist

With Search Engine Optimisation (SEO) being a critical factor for your website development, many overlook the impact your hosting environment can have in this area.

Being found in Google is critical for any business, so any advantage you can get over your competitors will always assist.

To assist you in your quest for better SEO we have come up with a simple SEO checklist that if followed will improve your SEO and give you the Google tick of approval. 

1. Australian based web servers

Having your servers located within the same geographic area as your customers is one of the key indicators for SEO. This means that if you’re running an Australian business, you need to have your servers located here in Australia.

100% of Conetix’s servers are located here in Brisbane, QLD, Australia. This gives the lowest latency for network connections to all Australians.

There’s only a 6ms latency (yes, 6/1000th’s of a second!) from our servers to Sydney, compared to an average of 200ms to the west coast of the USA where many other cheap hosts have their servers. That’s over 30 times slower!

Not only do you get an improvement in speed but you also get the added benefit of data sovereignty.

Being a fully Australian Company Hosted in Australia on Australian based servers you have the added security and peace of mind knowing that your website information complies with Australian data sovereignty laws.

2. Fast Servers

Low latency is one thing and having your servers in Australia is a good start, but you need to have fast servers to ensure your website loads quickly.

Any advantage of hosting with an Australian host will be lost if the speed of the servers is less than optimal. Many cheaper hosts cram thousands of sites onto the same servers and then limit the performance of each so that they can all remain running.

At Conetix, we don’t oversell our servers and only run the latest, enterprise grade server equipment. Systems such as the latest Dell Poweredge servers fitted with the latest Intel Xeon Gold CPUs (not the cheaper variants many other hosts use) are the core of our platform.

Our virtualisation provider Virtuozzo (who is the world leader in hosting software) and combined with running on the latest Enterprise NVMe Solid State Drives (SSD’s) provides you with a highly optimised environment with the fastest possible platform for your website.

3. SSL Enabled

Unlike many of the ranking indicators which Google normally doesn’t talk about, having an SSL enabled site is one where they’ve been very open about. 

While Google has initially said it will provide a small boost, their end goal is to ensure that all sites are 100% HTTPS based so this boost will continue to increase over time. 

Having an SSL for your site previously was an additional expense for your website (upwards of $100/year), which is why many didn’t bother unless they absolutely required it. However, Conetix proudly offers the Let’s Encrypt platform for all of our servers to provide free SSL’s for all websites.

Not only this, but the process is literally as simple as 3 clicks! Older, paid systems required email verification and manual installation of the SSL certificate and this could take 1-2 weeks to complete depending on certificate type.

4. OCSP Stapling

Now you have secured your website using a SSL certificate there is one simple step to add that additional boost by turning on OCSP Stapling for your certificate.

Online Certificate Status Protocol (OCSP) stapling is the standard for checking the revocation status of a digital certificate that is assigned to a website or web service, in simple terms;  is your website’s SSL certificate valid.

By turning on this feature you provide that slight improvement in website speed for your potential customers. With an improvement on website speed Google sees this as a ranking signal and also an added trust SEO signal.

If you want to know more about OCSP stapling here is an article on OCSP Stapling: Why should I enable it for my website?

5. HTTP/2 Enabled

By adding a SSL certificate to your website and securing all HTTP traffic to and from your website using HTTPS, you will now find that your web speed performance will be slightly affected.

This is because the connections take a bit longer to establish the encrypted connection.

This performance hit can be negated with HTTP/2. This is because HTTP/2 combine requests into one connection (known as multiplexing) and therefore means the initial negotiation only has to happen once. The even better news is it can actually give a site with a lot of resources a performance boost.

This connection can still handle multiple, concurrent requests so it will actually make it quicker than a more basic setup (where each individual request is processed from your browser to the server). 

All of Conetix shared hosting and VPS’s are HTTP/2 enabled by default so you can take advantage of this additional performance boost and in turn improve the way Google sees your website.

If you are unsure if your website is running HTTP/2 you can test your site using these websites tools link HTTP2PRO. https://http2.pro/

6.  Isolation and IP Reputation
– no noisy neighbour

Your ranking can be affected by other websites completely unrelated to yours if you’re on shared hosting or with a hosting company who has a poor reputation. Did you know that search engines know what other websites you’re hosted alongside?

What if your professional business website was associated with non-business related sites or websites which were known for spam? This could adversely affect your ranking without you even realising.

This also affects your email if you send email via your web hosting account too. Emails may be marked as spam by the receiving mail-server (ie your customers!) and even worse not delivered to the intended recipient.

To prevent this being an issue, Conetix takes two strong approaches. Firstly, we’re a business only web hosting company. Our sole focus is on professional entities only and because we don’t chase all of the market it means we only get the business focussed customers. 

Secondly, our Professional hosting as well as all Managed WordPress and VPS plans provides you with your own dedicated IP address. This IP is 100% yours and not influenced nor affected by any other website or emails outside of your control. 

7. Geographic based domain name

If your customer base is located in Australia it makes sense to use a geographic based domain name for our region.

A .com.au domain for a business when hosted within Australia works in your favour for both brand trust but most importantly the SEO gain being found local first.

Google’s goal as a search engine provider is to provide you with the most relevant result for your search and a major part of this is geolocation. 

8. Use the latest version of PHP

When speed is second only to content in the eyes of Google, one of the simplest things you can do is make sure you run your website on the latest version of PHP. 

What is PHP? PHP is the language that most web applications like WordPress use to run on modern servers. With 90% of new websites being built in WordPress and WordPress running around a third of all websites on the Internet the chances are that you are running WordPress and in turn running using PHP. 

The even better news is that if you are running one of the other Content Management Systems (CMS) like Joomla! or Drupal you are also using PHP and can take advantage of this simple change in version and gain speed improvements for your website.

The latest stable and fully supported version of PHP as of June 30 2020 is 7.4.7. PHP 7.4 sees the introduction of new features that improves performance and security improvements.

All of Conetix shared hosting and VPS hosting has PHP 7.4 available for you to use. If you would like to know how to take advantage of PHP 7.4 contact our support team as they are here to assist (even if you are not on our platform). 

9. WebP

Originally developed by Google, WebP is a new image format that improves the efficiency of image compression in order to greatly reduce the size of the images.

This means less bandwidth to load a website and therefore faster websites.  With Google using speed of a website as a key SEO indicator and Google originally developing the WebP image format it makes sense that web developers use WebP in all of their development website builds.

In the latest Plesk Obsidian 18.0.27 release, all PHP versions now use the latest GD image library so that all of the Conetix Web Hosting systems (and others of course) now provide support to generate these images.  

If you want to know more about WebP and the performance gains here is a full article on WebP: What is it and why should I use it?

10.  Reputation and Trust

Reputation and Trust has a broad scope when it comes to web hosting. As previously outlined in Tip 6 with Isolation and own IP address this is just one part of your overall strategy required to gain trust with Google and your end users as well as maintain reputation with Google and your brand in the marketplace. 

One of the most important ways of keeping reputation and trust is keeping your website up to date. Maintaining your website security by keeping your core, themes, plugins and extensions up to current release is key in keeping your valued reputation intact and builds trust over time.

As a web hosting company we can assist in a few ways. We can provide you with the right tools that make it simpler for you to manage and maintain your hosting or provide you with the right hosted paid solution. 

If you don’t have the experience or the time to maintain and manage your website and you are not paying your developer to update and maintain, then you run a very risk of being compromised. It is only a matter of time. 

Conetix provides the tools for you to self manage using Plesk WordPress Toolkit or the Joomla Toolkit to make it easier; alternatively you can leave it up to our expert team to do all the security updates on your behalf.

Our plans range from self managed to Managed with WordPress Smart Updates to Australia’s only real Fully Managed WordPress solution that is second to none.   

The version stability and long term support for security updates (thanks also due to the Red Hat release cycles) make it an excellent base platform to ensure we have both a secure and reliable system.

While nearly all of our systems have been using the release 7 (CentOS 7) variant, we’ve begun deploying newer systems to CentOS 8 now that some of the initial compatibility issues have been ironed out.

In this article, we’ll outline some of the new features rolled in and why they’re great reason to use for hosting.

Updated software management

For those used to using YUM (the package manager for Red Hat / CentOS), a new version is now available. Known as DNF (Dandified YUM), this features increase performance, increased flexibility through a far more detailed API, less memory usage and dozens of other improvements.

Nearly all of the commands are exactly the same, and you can still run as “yum” commands as it’s simply a symlink to the new “dnf” command. For example:

yum install httpd
dnf install httpd

Both of these commands call exactly the same thing, so you can use the old commands while you transition. We’ve definitely seen the speed improvement when running updates so already it’s a great bonus!

OpenSSL 1.1.1

We’re lucky enough that the use of NGINX across our hosting platform allowed us to roll TLS 1.3 out last year, but the inclusion of OpenSSL 1.1.1 in CentOS 8 means all services (including Apache and outbound PHP) can now use TLS 1.3 directly as well.

This allows for greater security and therefore greater protection of data against Man in the Middle (MITM) attacks.

PHP 7.2

While we use Plesk to provide updated PHP versions (including PHP 7.4), having PHP 7.2 as the base version allows for easier compatibility with systems such as WP-CLI by default.

MariaDB 10.3

Like PHP, Conetix had always run the latest, compatible MariaDB version (10.3) on our systems but this required replacing system defaults with externally packaged ones (from MariaDB themselves).

Having this now as the distribution default removes one extra level of management and potential update risk as there’s more testing involved with the system defaults.

Updated Kernel

With CentOS-8 being based on the 4.18 Linux Kernel, this allows for all of the additional features and improvements since 3.10 (CentOS-7) to be incorporated. While some of these features have been backported for CentOS-7, having a more-up-to-date baseline allows for greater expansion in the future as well.

While the individual feature changes are too numerous to list here (a summary is available here for those really interested!), some of the key stats will give an idea on the level of change:

• 12,879 changes
• 1,668 developers
• 553,000 lines of code added
• 652,000 lines of code removed

Source: https://lwn.net/Articles/760690/

Increased support timeline

CentOS 8 will receive full updates until 2024 with security (and critical bugs) updates until 2029. Here’s a table to compare:

This means that if you install a CentOS 8 system today, you’ll be receiving security patches all way until May 2029!

Many other updates

If you’re using CentOS 8 in a non hosting environment then of course there’s hundreds of other features (including updated GUI etc) which may be applicable to you as well.

For a detailed overview of the new features and changes, please check out the Red Hat Enterprise Linux 8 Release Notes.

By providing a SSL certificate for your website you can now force all traffic for your website to use https:// – HyperText Transport Protocol Secure rather than standard https://.

With this change and focus on securing websites, browser developers like Google (Chrome) and Firefox started displaying secure and insecure site lock natively in their browser. Their goal is to provide a more secure Internet and provide trust from your website to the end user. 

So what is OCSP Stapling?

Online Certificate Status Protocol (OCSP) stapling is the standard for checking the revocation status of a digital certificate that is assigned to a website or web service, in simple terms;  is your website’s SSL certificate valid. 

To understand a little more about OCSP stapling we need to cover two parts; OCSP itself and the extension stapling.

OCSP itself is an independent protocol that allows the web browser to verify the SSL certificate.

Validity. The browser checks the website’s certificate in real time against the Certified Authority (CA) and responds with a good, revoked or unknown. With this verification process each request  or query has to be processed in real time and incurs a resource cost. 

This cost is not only a bandwidth cost, backend server resource cost but also an end user browser cost in terms of slower performance. The busier the website is the more resource cost and in turn the slower the website becomes.

To overcome this resource cost limitation stapling was introduced and as the term suggests, the additional protocol is stapled or added to OCSP to improve this cost and speed up the process between the end users browser and the website. A time-stamped OCSP response is stapled to the request which eliminates the need for the end user browser to contact the CA directly.

Why would you use OCSP stapling?

This simple addition to your website’s SSL certificate improves both security and performance. This in turn provides trust in your website and end user confidence in using your site. Once again it also provides a ranking signal for Google which improves ever so slightly your overall ranking of your domain and website itself.

Increases Trust
Speeds up your website
Improves Google SEO Ranking

How can you take advantage of OCSP Stapling?

The good news is that OCSP stapling has been implemented by all the major web server providers like NGINX,Apache, LiteSpeed and Microsoft Windows Server.

With the major web server providers implementing this protocol, many server management panel providers such as Plesk, have taken advantage of this and have created a simple way to implement and manage quickly without any technical expertise.

How can I check if my website is using OCSP stapling?

The simplest way to check is to use online tools like SSL Labs SSL test. 
Simply go to https://ssllabs.com/ssltest and type in your domain name. 

It should show the following on the first page of your report if you are using OCSP Stapling.

If you are hosting your website with Conetix or have your own Plesk Virtual Private Server with Conetix, you can add OCSP stapling to your website or sites now. 

If you don’t have this option with your current provider we would love to talk to you and see where we can assist.

More Technical Resources.

If you want to know more about OCSP stapling and how it all works the following are some great articles that you may find useful.

Cloudflare – High-reliability OCSP stapling and why it matters

CA Security Council – The Importance of checking for Certificate Revocation

Disclaimer: The views contained in this blog are my personal opinion and based on what information I can see publically available. As I don’t have any insider information, they may not reflect what actually occurred.

Too much focus on competing with AWS

Ninefold had a number of press releases about pricing and “matching” Amazon’s prices, and this is the wrong focus. Price isn’t the deciding factor why people use AWS, it’s the convenience.  Unless you’ve got billions in backing, you’re simply never going to compete with the likes of AWS and expect to win. It’s why companies like Azure and Rackspace are the only ones who competitively compete, they have massive teams and massive marketing budgets to back them. It’s like expecting to go out and build a better phone than Apple or Samsung yet do it without the 15 years prior experience and 1/50th of the budget.

This isn’t to say that there isn’t room in the market for other providers, but they need to cover niche markets and niche opportunities.

The Register called it back in 2013. Here’s a direct quote:

The survivors will move into roles as resellers and managed services providers who make public cloud easier for those who don't like to get hands on with the big boys. This is happening already. By 2015 we'll see exits from the cloud caper.

Cover what the big guys either can’t do or don’t do well. If we take the iPhone analogy, there’s plenty of opportunity for phones with embedded medical features or phones that cover a niche part of the market (eg the elderly). Apple won’t ever compete in this market space, which leaves opportunity for others.

Focus

This is one of the big criticisms of Ninefold from an outsider’s view. One minute they’re an Infrastructure as a Service (IaaS) provider, the next minute they’re a Ruby on Rails (RoR) provider. Then, an expansion into the (very highly competitive) US market. Then, they’re an IaaS focussed provider again. The focus kept shifting without a clear goal of who they were and what they were trying to achieve.

Technical Debt

This is one thing that every company hates, especially if they’ve developed many of the critical systems themselves. Here’s the statement from the Ninefold press release:

Significantly more investment is required if we are to make what we’ve built go to the next level. After an evaluation of the underlying technical platform, much consideration and deep reflection, we have decided not to embark on this journey.

To me, this sounds like they’ve hit either issues scaling or to fix some of the components then they’d need to do a forklift upgrade of their existing systems. This is generally extremely costly and very risky. Regardless of if it’s the physical hardware (SAN’s are great for this limit) or the software, once you’ve reach this point it’s very hard to free yourself from the problem.

What makes Conetix Different?

If we’re going to analyse one of our competitors then it’s only fair that we look critically at ourselves. As a 15+ year veteran of the hosting world, Conetix has seen things change over time and not only survived but grown. Being brutally honest, we’re only a small player in the big cloud game but we think this is an advantage, not disadvantage.

Our Support

This is one thing which we’ve strived not to compromise on and based on the feedback we receive, I think we’re doing it well. Unlike other providers, we have always ensured that our support is Australian based and of a high standard. Our call queues are non existent and in most instances, the technician you talk to on the phone will be the one who resolves your issue.

Our Platform

We’ve been a strong believer in container based virtualisation and have been using this as our preferred virtualisation type for over 10 years. This is using the Odin Virtuozzo platform, which this year ticked over the statistic of 1 million deployed containers.  Combined with their distributed storage platform (where all data is replicated 3 times), this provides is with a highly available, highly redundant platform.

Performance is great too, running tests via ServerBear.com puts us as the fastest provider in Queensland and in the top 5 in Australia for both CPU (UnixBench) and IOPS. Compared to the big guys, we’re up to four times faster for the same money.

Australian Owned

We’re all based here in Australia and owned by Australians. Decisions aren’t made based on profits nor what some overseas company directs us to do, we control our own destiny. Whatsmore, we a profitable company too. While this may seem odd to point it out, it means we’re a sustainable business and a reason why we remain while others fall.

Future Planning

The advantage of being small means we can be fairly quick to react when trends change and don’t carry a lot of technical debt. It also means we can’t afford to have dead weight nor have legacy systems hang around. Like the trend towards Docker based deployment, we’re constantly refining our offerings and ensuring we remain focussed and relevant.

The 2015 year has been a big year of transition for us and 2016 is where a lot of the new tools and systems we’ve been working on will finally be released. Like always, we’ve been approaching this in a cautious but calculated manner so that we don’t trip or push systems out before they’re ready.

An Olive Branch

We understand that many businesses and companies who chose to host with Ninefold now have to make some difficult decisions, so we’d like to make this decision easier for you. Not only can you run a 90 day trial our platform for free but you’ll have our expert team on hand to assist with migrations (also for free). Please don't hesitate to contact our team to see what we can do for you. 

We’re setting up a new production web server for our own site and as it’s a chance to start fresh, the thought of course turned to “what’s the best web server for our site?”. After looking around at various benchmarks and reviews of the more common web servers, none of the benchmarks seemed to have been run in the last few years or focussed on thousands of connections with static content. This wasn’t the scenario I wanted to see data on.

So, I set about running a few benchmarks on what I considered to be the top 3 Linux based web servers for a moderately busy site. This is why I’ve labelled the article “Part 1”, as I want to cover multiple scenarios in a few follow-up articles to encompass a variety of scenarios. For this test we’ll be using WordPress, however I’ll be testing other platforms in the follow-up articles as well.

The Environment and Test Limitations

For these tests, we’ll be using a CentOS 7 based Virtual Private Server (VPS) with 2GB of RAM and 2CPU’s allocated. This is a fairly vanilla entry level system which many of our clients use, which means it’s a great starting point for relevance to our clients (and hopefully others as well). Being somewhat resource limited means that we also need to consider the resource usage of the web server as well as the performance.

WordPress wise we’re simply running a vanilla install of WordPress 4.1. We’ve benchmarked WordPress twice in the past (WordPress 4.0 Performance Benchmarking and WordPress 4.1 vs WordPress 4.0 Performance Comparison), so we know the rough performance baseline as well as performance tweaks required to make WordPress sing. This time around we haven’t installed any plugins, nor made any changes to the base install. We’re also running the MySQL database from the same VPS, which is common for smaller sites. This isn’t what we recommend for large sites with high traffic loads but again we’re targeting the smaller, more typical deployment scenarios.

We’re also only calling the main page, so while it gives us some general data it’s not perfectly indicative of the actual user performance. Only real world testing can give you this and it’ll vary significantly depending on the exact site configuration.

The testing is being run from a separate VPS on the same compute node in order to eliminate any network issues. The basic test we’re running is with 5 concurrent users and making 5000 calls to the homepage. Our Apache Benchmark call looks like this:

ab -c 5 -n 5000 https://benchmarks/wordpress/ 

The 5 concurrent calls is to simulate a moderately busy site. It should also be noted that 5 concurrent calls doesn’t translate to 5 concurrent users. Similarly, the requests per second also do not translate directly to users per second. These actual figures and the translation between will vary from site to site and vary across different platforms. The 5 concurrent connections will however give a reasonable approximation of what I consider to be moderate to high usage for a business website.

Apache 2.4 + mod_php

Versions 

• PHP 5.4.16 
• MySQL 5.5 (MariaDB)
• Apache/2.4.6 (CentOS)

Even with the latest Apache 2.4, the default PHP configuration is through mod_php. This means that PHP is loaded as a module within Apache and runs as an embedded process. There are of course many pros and cons to running this way. Without going into a full comparison, essentially every Apache process needs to load PHP, regardless of if it needs it or not (eg when serving static files).

Lets look at our results:

Requests per second:    12.75 [#/sec] (mean)
Time per request:       392.196 [ms] (mean)
Time per request:       78.439 [ms] (mean, across all concurrent requests)

The important figures here are the requests per second and the mean time per requests across all concurrent requests. So in our testing config, the vanilla WordPress site is capable of just under 13 Requests Per Second (RPS).

I also use a basic little one-line script (from here) to show the number of Apache processes and the average memory per process. Here’s the script:

ps -ylC httpd --sort:rss | awk '{sum+=$8; ++n} END {print "Tot="sum"("n")";print "Avg="sum"/"n"="sum/n/1024"MB"}'

And the output:

Tot=187024(9)
Avg=187024/9=20.2934MB

In this test scenario, Apache had 9 running processes with an average of 20MB each. Obviously if we were also serving out static content then we’d see more processes and the memory usage would be higher. This is when running a very basic WordPress instance too, if we’re running a much more intensive software suite like Magento then we can expect this resource usage to be much higher. It’s something we intend to cover in one of the future comparisons.

Apache + mod_php + disable Apache modules

One of the major complaints I always hear about Apache is that it’s “bloated”. The downside to having a large amount of functionality built in is that you need to load all of these features when running Apache. Thankfully, Apache is quite modular and we can simply turn off a lot of the unused features.

Note: Here be dragons. Turning off features without understanding the implications nor what they do is a disaster waiting to happen. Do not do this without understanding the implications.

I’m not going to list all of the modules I disabled, simply because I don’t want this to be a how-to guide or to have others blindly disable features without understanding the implications. I disabled about 20 modules in total, which included some of the mod_authz, mod_dbd and similar because I knew they weren’t being used for this basic site. Here’s the results:

Requests per second:    12.95 [#/sec] (mean)
Time per request:       385.967 [ms] (mean)
Time per request:       77.193 [ms] (mean, across all concurrent requests)

The performance results are virtually indistinguishable, which is what we expected. Where we may see a difference is the memory usage, since the modules still need to be loaded even if they’re not being used. Here’s the result of our little test script:

Tot=168388(11)
Avg=168388/11=14.9492MB 

There’s certainly a drop in memory, but since the number of processes also varied, we can only directly compare the total result. The difference is 182MB vs 164MB with the some of the modules disabled. A difference of roughly 10% isn’t a big gain, so it would only be worth doing if you have a very large Apache installation or if memory usage is absolutely critical.

Apache + mod_fcgid

Next up was switching Apache to use mod_fcgid to implement a FastCGI call to a separate PHP instance. The tests were re-run and as the PHP processing was now performed separately, the memory used per Apache process dropped to 2.7MB. Of course, we now have the PHP instances and virtually the same system level memory usage (as measured by running “free” on the server). However, it means that having Apache serve static content is more efficient as it won’t have to load PHP with each process. Since this is what a typical webserver does, running PHP separated from PHP makes great sense.

But what about performance? We’re now achieving 13.35 RPS, which is roughly the same as running mod_php.

Apache + PHP-FPM

One of the newer methods of the FastCGI implementation is via PHP-FPM. This has been the “goto” method to implement more efficient PHP based systems.

Our result? 13.33 RPS. Memory wise, it’s roughly the same as both mod_php and mod_fcgi. There are of course other advantages  to PHP-FPM which aren’t measured by performance (such as adaptive process spawning), so even if there’s no performance gain for a WordPress site it’s worth considering.

Nginx + PHP-FPM

This is the most common scenario (nicknamed the LEMP stack) which many recommend as the best fit for high performance PHP based sites. Nginx is certainly a powerful system and was designed to beat the C10k problem. This means it’s designed to handle tens of thousands of concurrent connections without degrading the performance. It does this by using events instead of threads, which is a more efficient system at high usage levels. While this isn’t the limitation we’re hitting here, we’ve benchmarked it anyway to if it provides any performance gains.

How does it perform for our scenario? 12.89 RPS. While it’s slightly lower than Apache, it’s close enough that it’s not statistically significant. 

Nginx + PHP-FPM + Opcache

As we’ve found from previous WordPress benchmarking, using Opcache to eliminate the need to continually recompile the PHP code made a significant difference to performance. The tests for this scenario also hold true. With Opcache enabled, we can now achieve 35.36 RPS. Like we found with our previous benchmarking, the difference is significant Essentially, we’ve nearly tripled the performance of the system.

If you have your own dedicated VPS, this is clearly very quick and easy performance gain with no additional cost.

Apache + PHP-FPM + Opcache

To confirm that the above Opcache boost is just as applicable to Apache, we reran the tests with Apache and Opcache enabled using PHP-FPM. The result is 37.13 RPS, so roughly the same performance as the Nginx configuration. Again, regardless of your webserver of chioice, this is a great increase.

OpenLiteSpeed

The LiteSpeed Webserver is something I’ve heard plenty about, but never actually used myself. It’s heralded as a lightweight and high performance webserver, which like Nginx is event driven. To test, I used the open source variant called OpenLiteSpeed. According to the LiteSpeed Tech website, the performance features should be the same as the commercial version.

Installation was quite easy and as an added bonus there’s a neat web interface to manage everything from. PHP is also specific to OpenLiteSpeed and needs to be installed separately. We went with PHP 5.4 like the rest of the systems so that it’s directly comparable.

And the performance? We managed 13.35 RPS. This is without the opcache running, which means that the results are perfectly inline with the Nginx and Apache based systems. Like Nginx, I’m sure the increased performance will come from higher traffic environments and it’s something we also intend to test further.

HHVM + Nginx

If you haven’t heard of HHVM, it’s essentially a virtual machine which uses Just In Time (JIT) compilation to optimise the executed code. The main team involved with (and who originally released it) is Facebook, who run the world’s largest PHP based application. Optimising a system which handles millions of concurrent users is no small feat, so they should know a thing or two about getting PHP to perform!

One key point to remember is that HHVM isn’t 100% compatible with all PHP code (but it’s improving all the time). Most of the common PHP platforms will certainly work (like WordPress) but you may run into some small problems with custom code or complex systems. Basically, you need to test and you need to test it properly.

Performance wise? Well the numbers certainly tell the story. We can now serve out 93.95 RPS! This is a massive difference and betters the opcache improvements by a factor of nearly 3. We’re now talking an improvement of over 7 times the stock Apache configuration, all without additional hardware.

If your site and code is compatible with HHVM and you want to extract every last bit of performance from your system, this is certainly the way to do it. It’s something we’re going to be watching closely as the project matures!

Conclusion

Right, if you’ve made it this far then well done! There’s a few things which need to be re-iterated here so that the results are used in the right context.

Firstly is our test scenario. It’s a limited test scenario using WordPress on a small VPS. This is what the results are based on and they only reflect this scenario. You can extrapolate the results slightly for your environment, however the clear message is conduct your own testing for your environment.

Under a moderate load with a very basic WordPress install, it’s clear that the underlying web server doesn’t significantly contribute to the performance nor the amount of users the server can handle. With HHVM, we were able to sustain over 90 requests a second. This translates to over 7 million hits a day if it was sustained for 24 hours. Even if you said the site is only busy for 6 hours a day, that’s still nearly 2 million hits. That’s still a very busy site! What would be the result if you did nothing? Even at our starting figure of 12 requests a second, you’d be able to sustain a million hits a day (if evenly spread over 24 hours). Here’s a quick table to summarise what’s available: 

When looking at these figures, you’ll want to ensure your server can handle the peak load and still have plenty of burstable headroom.

This brings us to our second point, the age old “premature optimisation is the root of all evil” yet again sings true. Work out where your true choke points are and attack those first. If 95% of the load on your server is the PHP code compilation then ensure you’re running opcache and if it’s a mostly static site then go for full page caching. If your code is compatible, go the whole hog and use HHVM.

Thirdly, we’re regularly told “don’t use Apache” or “Apache is bloated” and it’s somehow insinuated that using platforms which are decades old somehow translates into poor performance. This isn’t the case. Conversely, it doesn’t meant that using other web servers such as Nginx or OpenLiteSpeed are necessarily a bad thing. Both are very highly capable platforms and being event driven will certainly scale well. If your site is going to be receiving more than a few hundred thousand hits a day, then you’ll be well served by any of the webservers tested.

Lastly, let us know what we should cover next? Do you want to see more concurrent access? On a larger server? Running Magento? Please just leave a comment below to let us know.

For a business to host this type of technology a substantial cash outlay is required. By leveraging from a cloud hosting provider's existing infrastructure a business can reduce the costs of doing business on the web and have a mechanism to grow. So in general a cloud based architecture now provides a more scalable infrastructure for business and everyday web users.

If your an everyday web user with a blog your blogging site may well be hosted in a cloud based environment. What this means from the hosting point of view is that it can be easily moved from physical server to physical server at the click of a mouse, its memory needs can be increased as required and if its getting real busy thanks to the high quality content you provide then its CPU and storage resources can be dynamically increased as needed.

Applications like WordPress are incredibly popular and dominate a large chunk of the Internet, the remainder of web traffic comes from a pool of less common apps and your biggest players on the Internet, like news sites, eCommerce stores, search engines and the like.

Hosting these apps has moved from physical servers to virtual machines to container based virtualisation. Virtual machines provided a software mechanism to enable more bang for the buck from the pool of under utilised physical servers most business had running. Container Virtualization goes one step further by sharing the servers core operating system components in a highly secured but very dense environment so that even more virtual environments can be deployed from the same server.

One of the biggest issues in Internet systems is doing updates, particularly security updates. The more virtual environments the more difficult it becomes to perform updates that are going to work first go and provide no disruptions. This is often due to the way the application environment has been built or deployed by the users who purchase the virtual machine resources. There are other reasons but the core issue is that testing an application in a development environment and then running it in a production environment usually results in two different outcomes.

The last 12 months has seen a new cloud technology come to maturity. The big move is to host your application in “Application Containers” and the #1 (and only) application container environment available right now is called Docker.

Application Containers

Docker differs from a virtual machine or normal container as its a package environment delivered as an image that's instanced on the web/application server. It enforces a discipline for the developer of the application to package the app for deployment in any infrastructure. So testing on a laptop will produce the same result as running it in a large cloud infrastructure.

The original philosophy of Docker was one application – one container, but realistically a web server, cache engine and database server support can easily be packaged together as a single image and with access to persistent shared storage that container could then be instanced inside a cloud and moved, scaled or redistributed as often as needed. Additionally the application container can also be used as the basis for a new image and repackaged. With repackaging there is no need to worry about the size of the image's file system, it auto scales to suit.

From a hosting perspective Application Containers need more plumbing to put multiple web sites together on the same server, they also need disk that can be shared into the applications image at run time.

From a businesses point of view, where the developers and architect understand how to scale web technology a loosely coupled dynamically scalable system can be designed and built, then deployed just like any other application image.

From a security point of view, there is total isolation between each application container and the OS it is running in, the attack surface of an application container is smaller and hence less vulnerable.

For the end user, cheaper hosting that can be run anywhere is just around the corner!

One thing I often find people new to the hosting side of web development get caught on is how Domain Name System (DNS) works, and the difference between updating a Name Server (NS) record for a domain and an individual IP address within a host file. While this may seem confusing, a little understanding of the technologies and protocols involved can help demystify an otherwise complex subject.  

In a nutshell, DNS is what allows you to type www.google.com.au into a browser and it returns google’s home page. When you submit a request, the browser sends that request to your local DNS server (generally managed by your ISP) and this server recursively queries other DNS servers to find the record you requested. The IP address is then used to resolve to the correct server, the one that contains www.google.com.au.

Essentially, DNS is a hierarchical naming system for networks, like a phone book. It stores and shares records about the location of websites, and converts domain names from human readable words (www.google.com.au) into the format which computers need to communicate, IP addresses (74.125.239.56).

Domains – more than just a name

Domain names are managed by registrars or companies reselling on behalf of a registrar. Once a domain is registered, a domain is recorded in one of the various Internet organisations authoritative databases, depending on the domain extension. For example the records for .au domains are managed by AUDA. This prevents domain name double ups, and ensures that for every domain name there can only be one true record.

When domain names are looked up by DNS it is done in the reverse order we write them. Continuing with the example of www.google.com.au, the first record search is in the “.au” pool of records. From within that pool it narrows the search to the “.com.au” records, and finally it searches for “google.com.au”. This process is called a recursuve lookup, and occurs at the Top Level Domain (TLD) Name Server. The TLD server will then return which Authoritative Name Server (NS) holds the records for the domain name. This is indicated by records displayed similar to the following: 

ns1.google.com
ns2.google.com 

Its all about authority

An NS record attached to a domain name points to an authoritative name server, a server which contains a host file. A host file contains a list of all the various records attached to a domain name, including the domain name itself, any subdomains, mail records and IP addresses; all the information required to make a website function and become accessible via the Internet.

If you think of DNS as the phone book records for many domains, then a zone file can be thought of as the phone book records for one specific domain. It is important to note that the users don’t technically edit the zone file, they usually update records via a web based control panel such as DNS settings within Parallels Plesk Panel.

Why does it matter?

As I mentioned before, those new to the hosting side of the web can sometimes get confused or overwhelmed by how DNS works. And at some point it’s very likely that you’ll need to update details like A records, CNAME records, MX records and NS records, and an update to any one of them has profound consequences, so getting it right matters.

If you want to change the authoritative name servers, to point it to a new host file, then you are making a NS record change. This must be done at the registrar. If you want to change the IP address that a website resolves to, then you need to update the zone file. These changes need to occur at your domain’s authoritative name server, and normally through an easy-to-use control panel.

Wrap Up

Knowing how DNS works, and the various technical names and processes involved not only provides a good overview of how the Internet works, but can also save you time and confusion when making changes to records for a website. Thankfully, we have easy-to-use web control panels which take away much of the confusion and complexity to configure DNS servers. Many systems also automatically add the required settings for you, meaning you don't need to touch a thing. If you're ever in doubt or confused, you can always contact your hosting provider who should be able to assist you to edit or update records.

Whether it’s text, image, or audio based content you wish to share with the online world, CMS platforms have developed so much that content formatted in almost any way can be shared freely and easily via the World Wide Web.

Many sources have cited the top three CMS platforms available to content generators now as WordPress, Drupal and Joomla, because of their no-cost, open-source models, that allow creators to share just about anything they want with whoever they wish.

However, before diving head first into the world of CMS platforms, it is important to understand precisely what features distinguish these three from their competition.

WordPress

Firstly, WordPress. WordPress is a free blogging tool and CMS based on the PHP and MySQL systems, which hosts more bloggers than any other blogging system on the Web – a staggering 60 million plus!

WordPress benefits bloggers and content sharers through its easy-to-use layout, and guides that assist users in understanding the full breadth of the options available to them on the site.

While users can utilise free themes to make their blogs more attractive, the option is there to also create custom-built themes, though this requires a solid understanding of CSS and PHP, the programming and coding languages that underlie WordPress.

Entry level bloggers wishing for theme alternatives are forced to purchase content packs if they are unable to create their own, defeating the purpose of the free aspect of WordPress that is so very appealing.

Drupal

While WordPress is favoured by designers, Drupal is chosen far more by developers when it comes the CMS.

Being the most open to customisation, Drupal is perfect for those wishing the personalise their site, offering users access to thousands of pre-built themes and templates free, that ensure the process of web development is as pain-free as possible.

However, the expanse of pre-built features means Drupal comes with far slower loading times that its competition, and due to its relative modernity, often leaves users struggling with compatibility issues.

Joomla

Finally, there's Joomla. If you are needing an interface capable of hosting a large amount of articles, Joomla is for you.

Out of the three aforementioned CMS platforms, Joomla offers its users the most powerful yet most user-friendly interface, without finding you need added features, though Joomla stands somewhat in the middle ground when it comes to comparing the three.

While WordPress is user-friendly, is easy to style and makes basic tasks easy, and Drupal allows ample user customisation (following a slight learning curve), Joomla is not as blatantly easy to operate, nor is it as easy to develop into something of your own.

Wrap Up

Though the three have much merit, offering the online content sharer a unique and relatively stress-free content management experience, they each come with their pros and cons, and at the end of the day the decision on which to host your content should be driven solely by personal preference.

In the Beginning….

Before Cloud became a marketing buzzword and even before virtualization was a common technology, a web site would be housed on a physical server, this was generally not an optimal use of the server's power as most servers would be idle for most of the time. As communication links became faster and web traffic increased, server utilisation began to increase. As technology evolution has seen even more power from CPU's the introduction of virtualization technologies from numerous vendors began to seriously utilise this power and so was born the Hypervisor from vendors like VMWare and later Microsoft with Hyper-V.

Virtualization allowed a hosted operating system to utilise the hardware resources as if it totally owned the resources but in reality the Hypervised instance was given access to the underlying CPU, Memory, Network and Disk storage in an emulated, secure and controlled manor by the Hypervisor, since it had direct control of the underlying hardware. This model alone revolutionised the computing world at the server level, (not so much at the desktop level) and has done so for over 10 years now.

The Rise of Containers

With the Hypervisor market cementing itself as a rock solid reliable technology, an open source movement began to develop a “Hypervisor like” environment using the Linux environment as the hosting platform but with isolation and resource management built in. This enabled multiple users to host applications in isolation to each other, those applications could be anything but hosting web servers was the primary use. The hosted environment looked like a complete working operating environment, it would have its own file system, network address, memory space, users and applications just like a Hypervised environment but without the overhead of a separate Hypervisor. The result could realise an additional 10% to 20% performance gain by removing an entire software layer from the equation. So was born the “Container” environment.

Container Based Hosting

Organizations like Google which once ran a single Operating system on a hardware node now had the technology to run several instances of their operating systems in what was soon to be known as “containers”. This dramatically increased their available computer resources. The open source group leading the Container concept called “Open VZ” went on a slightly different path and were eventually snapped up by a company that is now known as Parallels. At Conetix we use the Parallels Container based virtualization software, for windows  known as “Virtuozzo” and on Linux its Parallels CloudLinux, so many of the Open_VZ tools are similar and Parallels has given much of the Container virtualization code back to the Linux and Open_VZ community over the years, partly in good faith but also to ensure its in the Kernel in every release and not as a patch set that needs to be applied later.

Like most open source projects, different offerings of Containers became available, Linux Containers also known as “LXC” is a different variant that uses the Container Virtualization support  that Parallels gave back as well as “cgroups” from Google and Linux namespaces. There are no large scale commercial deployments of LXC but it's support is growing with the advent of Application Containers developed by “Docker”, more on this later.

Inside a Container

From the end users perspective, hosting their web site inside a container is no different to hosting it inside a Hypervised Linux environment or on a physical server.

From a logged in user's perspective a container looks just like any other Linux environment and on a Parallels Virtuozzo for Windows system your RDP session looks just like a fully blown windows environment (yes you can get containers for Windows right up to Windows 2012!). In a Linux container all the same tools are present, you can do a process list, start every application the same way, you have daemons and the standard file system mount points look identical, so there is a /etc, /dev, /usr, /var and so forth.  

The scheduler “init” is running to schedule your applications and each container has its own “init” process which from the hardware nodes perspective is just another process running.

But under the hood the container is doing some interesting things. You and the 8 dozen other containers are most likely running the same processes but you each don't have an individual copy even though the “ls” command shows your /bin directory is full of programs, instead you are sharing a “template”, a neat design where all the apps that come with the operating system and many of the most common applications like the LAMP stack are packaged together as groups of files hosted by the hardware node's operating system and virtual symbolically linked into each container. This includes configuration files as well, unless you modify them, when that happens the operating system copies the template file (called copy on write), removes the virtual sym link and puts your modified file in your file system, The space saving is enormous, with only locally created files existing in your file system.

At a disk level, your container looks like a file, just like a VMDK file in Vmware or the equivalent disk image in Hyper-V, but in most container offerings the file system is thin provisioned. So if you need to scale up your disk space (or reduce it) that can be done on the fly. From a virus checking point of view, your container's file system is mounted under a special mount point on the hardware node so system tools at the hardware node level can safely and securely check every file if needed.

Container Density

From a Cloud vendor's perspective a container based infrastructure means the density of containers can be dramatically scaled up compared to a hypervisor based environment. At Conetix we scale the cloud servers to keep the load optimally balanced so that memory and CPU is available if containers need to burst their CPU and memory usage. We can also dynamically migrate a container between compatible nodes when needed without scheduling downtime.

Resource Management

In a Container environment, the amount of disk, inodes, CPU and RAM can be dynamically provisioned without a Container restart, that's a big plus. Also a new Container's start up time is measured in seconds as the startup process has already occurred so its just a matter of starting the init process and the two dozen daemons that typically exist in a minimal Linux environment. For the Windows Virtuozzo nodes its slightly more to start a new environment but usually a lot faster than a typical VM bootup.

Containerised Applications

At Conetix, we are gearing up for the next wave of Container hosting, that's going to be both exciting and a revolution! Application containerisation is the latest technology push, spearheaded by “Docker”. Rather than buying a VPS (VM) or Hosted Container, you could end up buying just a container for your application, need a web server and database? Just buy the applications and join them up to build a working system.

For the majority of businesses, a single cloud hosted web site running WordPress, Magento, Joomla or some other web application provides more than sufficient capacity.  However, being a single instance of your website, any downtime of the website or underlying components may affect your business. So, if your online presence must be up close to 100% of the time then a better solution offering some form of High Availability (HA) is a serious requirement.

Once your business grows and traffic increases dramatically a normal site (even with all the performance enhancements) will start to reach some hard limits. Caching technology will provide some performance improvements but if the website data is not static and must be retrieved from a database or file system then these limits are going to be reached as user request loads grow.

The first hard limit will be the ability of the web server to server requests. Another limit will be the response time of the database server and finally the amount of network traffic flowing to the server will also become an issue.

Let's address these three issues with some easy to understand technical solutions.

Scaling out the Front End Webserver

Once you are pushing the bounds of a single server and you have exhausted the numerous performance tweaks that can be performed on it, then separating out the functionality of the server components is required. At this point an additional web server (or more) will be required.

There are a number of benefits to increasing the number of web servers servicing user requests. Without delving into probability theory, simple queuing theory tells us that if the number of arriving requests exceeds the ability of the processing service then the queue of requests will grow. But if we add more processing services to service the queue, then the queue will be at close to zero most of the time, much like people standing in line at a bank queue waiting to be serviced by a teller. 

If we add additional web servers we will reduce the overall load and service each web request in time.

Load Balancing

In order to direct traffic to our pool of web servers we need to have some mechanism in place to direct traffic to them, there are a number of techniques that can be implemented. The first and easiest is DNS based Load Balancing, this method uses multiple DNS entries with the same domain name but a different IP address of each web server. These DNS entries are served in a Round Robin fashion, whereby the multiple IP's are send out and the sequence is then repeated.

DNS Round Robin load balancing has numerous drawbacks, here are a few:

• Not capable of detecting offline web servers
• Unable to determine if a web server is overloaded
• Skewing of request traffic due to locality of closest/fastest responding DNS server

Conetix does NOT recommend the use of DNS load balancing for these reasons. Let's look at how a Smart Load Balancing solution addresses these issues.

If our two web servers are sitting behind a Load Balancer, traffic can be made to flow to all servers alternatively to maintain good response times, this is called “Round Robin” and if all servers are online and evenly loaded this works very well. If a server goes offline then pure Round Robin will not be ideal as requests will be directed to a server that will not respond, so a mechanism is needed to determine if the web server is operational, most Round Robin Load Balancers implement a heart beat monitor that polls the web server to determine if it is operational, with this in hand, Round Robin can continue to be used knowing that a website is responding. 

However, there is still an issue that must be addressed, a heavily loaded server will respond at some point so simply monitoring a web servers presence is insufficient. Ideally we need to monitor how quickly the web server responds and how much “Load” the server is experiencing to determine if it should have requests sent to it.

A Smart Load Balanced solution as used at Conetix can also monitor the load of your web server and ensure that requests are sent to lightly loaded servers in a weight Distribution Model as needed. A lightly loaded server will receive more requests, as the load on the other server decreases then they will receive more of the request traffic, eventually the traffic will reach equilibrium until a spike causes loads to rise. The Load Balancer will be monitoring this and routing traffic accordingly. If you consider an alternative hosting provider then these are excellent topics to raise.

If your on-demand load is very high then additional servers can be added to boost the service rate of requests and from the Load Balancers perspective, this is just additional configuration details that are quick and easy to implement.

Also consider that the typical Load Balancer Appliance will be implemented in dedicated hardware, so your hosting plan may have an additional monthly cost if you choose to use this service.

Application issues with scaling out

While the addition of more servers at first appears to be a simple solution, it introduces some additional technical issues at the Application Software level. The first issue is the need to replicate the software and data to every server and keep this in sync as updates are made. For example, the Magento eCommerce application stores product data in a database, but the product images and related media are stored in the file system. To solve this, replication of the image data can be performed when the next store instance is started.

An additional issue to be addressed is the persistent session data that represents a user's session with the application, this is data that is dynamically generated and maintained as a visitor interacts with the application. For example, a typical default install of the Magento software configures the storage of session data to the file system while WordPress session data is stored in a database. If the load balancing is working correctly, the user will most likely connect to a different server from the initial interaction and the session data will not be present on the new server if it's stored in the local file system.

There are at least 3 ways to solve this issue:

• Use Database Storage – Applications that use session data must be configured to store that data in the database.
• Use a Clustered File System – The file system can be clustered so all web servers see the same files and hence they see the same session and application data.
• Use Sticky Sessions – The user, on being redirected to a server initially is redirected to a specific server using a unique URL for the duration of their visit.

There are more solutions but we will limit ourselves to these three and address more technical solutions in future articles.

All web applications will have one or more of these technical issues, these technical issues must be considered and addressed prior to diving into any HA solution!

Persistent Data

Databases

Each solution outlined in the previous section introduces additional technical issues that need to be addressed. Firstly using the Database to store sessions will increase the number of queries on the database server. The tuning of the database cache will eliminate a lot of the performance issues as most standard database installation are installed with configuration tuned for reliability not performance. 

The introduction of a caching technology such as Memcache or Redis cache will address performance but adds another layer to our architecture.

If your application does not have persistent data stored in a file system and uses a database server to retrieve data and content then Load Balancing the front-end web servers is going to be achievable.

Clustered File Systems

If your application stores data in a file system, the using a clustered file system can easily solve the persistent data issue as each server will see the same files on the clustered file system. The cluster will maintain changes between nodes and most clustered file system implementations implement a replication policy so that “N” copies of the data exists in the cluster based on the belief that nodes in the cluster can go offline at any time. 

Using a clustered file system introduces delays in the data replication process as data is usually transported over a network link between nodes. If the nodes are directly connected on 1Gigabit or even 10Gigabit technology then this will usually not be an issue but if replication to a remote site is implemented there will be propagation delay inherit in the transport technology type.

The “Glusterfs” clustered file system is often used to provide reliable clustering of file systems between servers. It installs vary easily in a large number of Linux installations and has a simple architectural design that is quite logical and reliable.

Sticky Sessions

The phrase “Sticky Sessions” refers to a client remaining with a specific host in a session based transaction. Sticky Sessions are  often used with HTTPS traffic as the client generated session key is sent to the server on the initial transaction and all data transfers after that are fully encrypted, in our example, the load balanced host will detect the SSL session and maintain a session relationship between the client and the host. 

Often the load balancer will present the public key for the server(s) and act as a “Man in the Middle”, presenting encrypted traffic to the client but clear text to the servers, a design which is perfectly acceptable when the servers and load balancer are directly connected and clear text HTTP traffic cannot be snooped on.

Having the SSL session terminate at the Load Balancer does raise the processing load on the Balancer, something that the hosting provider will be monitoring for. At Conetix, we use multiple Balancers that work in a High Availability and session sharing architecture, they are smart enough to share the load between themselves as needed.

Content Delivery Networks

If your web application presents Images, Javascript and CSS content then a Content Delivery Network (CDN)  is an excellent way to deliver this data to your clients independent of your hosted web application.

The advantage of CDN, especially if you use a large provider is it can be dispersed across many geographic locations and if the delivery network can determine the location of the requesting client then the content can be delivered from a server close by. 

Cloudflare are very large CDN hosts who are capable of achieving Content Delivery from multiple geographic locations. To implement this functionality, the CDN server will need to cache the static content from your web application. 

A separate unique URL needs to be configured for CSS, Images and Javascript content. These URL's are then configured to the CDN provider. The net effect of this is that only traffic specifically retrieving application functionality is now serviced via your hosting plan and hence a reduction in traffic and reduction in request load.

The static content on the servers can be synchronised from your administration instance when changes are made and will automatically be synchronised by the CDN network as content expiry is checked.

Conetix is a partner of Cloudflare and we actively use their CDN services for the majority of our clients.

Where to from here?

Investigate the performance of your site, once all performance tweaks have been implemented and growth continues, review the scalability of the applications you use.

Implement a test website, build a second copy of the site and a database server holding a copy of your production web site. Implement a load balancing hosting plan and test all facets of your application. 

Failures are most likely in shared resources and files that are altered during the course of execution of the application. If data is stored in a local file system then look at a clustered file system solution.

Conetix manages a number of High Availability systems on behalf of our clients, combinig dedicated Load Balancing hardware with clustered storage and servers. If you've outgrown your current provider, please don't hesitate to contact us to discuss your requirements.