|
Cloudservers A look at the implications of cloudservers for database-driven websites, with special reference to CDN networks and the Blaze.io service.
CDNs or content delivery networks are cloudserver nets that spread server load physically and sometimes geographically, for better efficiency. A new service, Blaze.io, takes this concept and improves on it by adding some server speed enhancements. There are pros and cons to this approach, as may be expected: some sites will benefit and others may not.
These types of services are cloud-based, that is, they use distributed servers in different countries, often by arrangement with the Amazon S3 network, a huge global server network with very low bandwidth costs. They generally serve the content faster than most normal servers could do, and in some cases may also include additional enhancements such as improving inefficient web code by minimising and/or compressing it, and splitting the DNS between several additional domains.
DB-driven sites in the cloud
Database-driven sites are notably poor choices for cloudserver facilities, since cloning a server does not work when a database loaded with 2-way traffic is involved, as all servers will somehow have to sync their databases - which in practice is not possible, at least without serious issues. Therefore the most heavily-loaded DB-driven sites are the worst candidates, and a high-traffic forum is about the worst candidate of all. Cloudserver nets work well for static content, or sites with few regular changes. Example of a website that will not benefit
Here is an example of a website that will not benefit from this approach. The site, which we manage, is a high-traffic forum running on several servers at one hosting facility in the USA, with most traffic from the USA. It has a very efficient server configuration: a powerful database server or 'backend' that feeds several web-facing servers or 'frontend'. The webservers run Nginx, with Apache in the background running some ancillary services. This has proven to be the fastest of all configurations as there is only one DB server to worry about, and Nginx outperforms all other server apps including Apache, Lighttpd and Litespeed (and Windows of course); and more servers can be added to the frontend as needed. The only drawback is that geographically, there is some timelag to the other side of the world, but in this particular case we are mainly interested in North America, with Europe as a second consideration.
Of course, you need your own server tech as hosts tech support cannot normally assist here. Nginx unfortunately is entirely console run, there is no graphical user account management such as cPanel on Apache.
A heavily-loaded forum is the hardest-driven database site of all. There can be be multiple file changes per second, for example, and the disk I/O load on the DB server is intense. The problem is that on a large site that needs more than one server, you should remember that each server runs two-way traffic: users write to the database, and the new content is then served to all. This presents problems for multiple server configurations as somehow every server's database has to be the same as all others. There are timelag issues here, but the biggest issue is the fact that every server has to write to the disk all the other disk writes on every other server. Disk meltdown is an obvious issue. Cloned server configurations just don't work, as the servers usually can't keep up with each other and the disks break down due to the multiplied I/O workload.
The cloudservers would somehow have to sync their databases very frequently, and since this is all but impossible in real-time, the problem growing with the number of servers, the site will lag badly in terms of content updates.
These problems are load-related, ie traffic-related, so a quiet DB-driven site would present less problems.
Solid State disks
SS disks are, as might be expected, faster than the standard platter-style hard disks. Strangely, though, you can't use solid state disks to reduce the service life shortening effect of cloning database-driven servers, since these disks have for some reason proved in practice to die even faster than other types, contrary to expectations. Hosts with high traffic report that SS disks die faster than other types and they don't recommend them unless you want to pay a premium for their speed and short life - typically 6 months or less.
The short life of heavily-loaded SS disks is surprising and disappointing.
Local aspects for this particular site
In the case of the site discussed, here are the negatives:
1. This heavily-loaded DB-driven site is obviously the worst possible candidate for cloudserver expansion.
2. The current server set-up uses a big DB server backend and web-facing frontend servers running Nginx, and you just can't get any faster than that.
3. The traffic is mainly from the US and that's where the host is anyway.
4. The forum code can't be compressed much as it has few aspects that benefit from this approach, there is a maximum of 8% speed gain in pageload shown by testing, for local traffic.
5. Geographically remote traffic is not of primary importance to us. Its value may increase in the future.
6. 'Domain sharding' or splitting the traffic across several domains has negative SEO implications and we don't want to go down that road.
7. The HTML rewrites or other methods used to increase speed (especially if they involve any additional JS) may also affect SEO, and this is a sensitive area for us. Blaze.io
This service is an advance/improvement on the standard cloudserver CDN concept and does three main things:
1. It compresses some of the code in order to make the page load faster. Some HTML may be rewritten, and the code will be minimised and/or compressed. In other words white space in text will be removed and compression may be enabled.
2. It uses other domains to serve the content from, so there is no DNS bottleneck.
3. It serves content to visitors using the nearest server to them, which has pageload speed gains for remote locations.
Who this service would suit
Some websites will benefit greatly from this type of service, and some won't. Some in fact would be negatively affected.
These sites will benefit:
- Sites with static content, or content that does not change too frequently, who need more server capacity.
- Sites with globally-distributed traffic, where there has proved to be a lag for distant visitors.
- Sites with poor code that can be optimised successfully by 3rd party applications.
- High-traffic sites that don't want to buy more server resources.
- Sites with a slow or restricted main server who don't want to move.
- Sites who for some reason would be charged excessive amounts for more bandwidth as they grow. (Bandwidth used to be expensive but the cost has fallen through the floor, physical server resources are far costlier now. However individual arrangements may be vulnerable to high bandwidth charges for one reason or another.)
- Sites that don't need ultimate SEO optimisation.
Therefore heavily-loaded static sites with global traffic and poor code will show the best gains. Putting some of the load in the cloud will avoid the need to buy in more local server space and also improve efficiency for geographical reasons and due to server speed factors.
An interesting site profile for this type of modern bandwidth cost reduction and server speed optimisation approach is a static site on a shared server with growing traffic from other countries. In other words, a small but growing site that might otherwise be looking at buying a dedicated server could look at this new option first. The SEO implications need careful consideration, though. Who it won't work for
High-traffic database-driven sites with efficient servers and mainly regional traffic will not show sufficient gains to neutralise the probable content lag* and SEO negatives.
* Content lag only affects DB-driven sites put on the cloud. ConclusionCloudservers most likely won't suit busy forum websites, very busy CMS sites, busy interactive sites of other types, or any other DB-intensive sites, especially those with predominently local traffic.
Ecommerce websites are an interesting question. They normally don't suit, because the remote servers are not able to sync the main application database or connect with the payment gateway due to SSL issues (encryption certificate / seal). Blaze.io will suit expanding static content sites, especially those with poor server speed or poor native code, that need more bandwidth at lower cost or better geographical placement. It may suit some other site profiles as well. The service is an improvement on the standard cloudserver or CDN offer. It may also work as a distributed backup network so that if the main site goes offline, the site stays up.
|
Cloudservers
