CloudKick’s  monitoring  tool is web-based and tracks load, CPU, bandwidth, and memory. It can also run  diagnostics tests and send SMS and email alerts when thresholds are breached. Using CloudKick Hybrid, admins could monitor the performance across several cloud hosts (such as AWS, Rackspace or GoGrid) from one central web console. With the addition of CloudKick Hybrid, on premise severs can also be monitored from the same console.

Currently CloudKick is primarily a monitoring tool but it has demoed cloud mobility solutions which allow admins to seamlessly transfer apps between cloud services from the CloudKick management console.

• A detailed review of Windows Azure.
• A pricing comparison between Azure and Amazon AWS.

1. 301 Redirects

Unless you are just moving a site between two server and using the an identical platform it is likely the page urls will change which means that all inbound links and search engines will be looking unsuccessfully for the old page urls. A 301 redirect from the old page to the new page is the method all search engines prescribe for switching page urls.
In Apache this can be done in the htaccess file or each of the old pages can have a 301  redirect header to point to the new page (this is the only method available of ASP.NET sites).

2. Prevent Pages from Being Indexed on the Staging Site

Before the site goes live the content will be migrated to the new location and there will be testing of the new site which means it will be visible on the internet. Whilst it needs to be visible for testing you will not want search engines to start spidering your site and attempting to index the content under its testing url. The testing url is typically not published anywhere but search engines always seem to find new site – for example  when you are communicating with other site workers or freelancers sometimes they will put a  on a forum.
Simply add a robots.txt file to the root of the site with the text :

User-agent: *
Disallow: /

This will prevent any indexing, but be sure to remove this when the site goes live.

3. Communicate with Site Users

If the migration is accompanied with a redesign it is usually obvious that a migration has occurred but you should always inform site users of what is going on with the site that they visit. Normally a notice on the site, email, and twitter notification is best. Try involve site users as much as possible to make them feel more engaged with the site and also help in the trouble shooting – ask users to let you know about bugs or usability issues and maybe run a small competition with a giveaway.

4. Watch For  Errors

Regardless of your testing, there will be errors once your site goes live. Firstly, an error landing page should be made to let the site fail gracefully and also encourage users to communicate with you if there is a persistent issue. Bugs should be tracked, normally through a bug capturing database but just looking at site logs can be sufficient for simple content sites.
Once the live is live you should also closely watch the site’s response time for indications of site issues or problems with the new host. Pingdom is a good tool for this.

5. Backups

Backup the entire legacy site and include everything that is required to recreate the site, database, config files, web pages etc as you may need to reestablish the site later.

6. Image / File Links

Most migrations will involve a change in directory structure so images in the pages and links to files or downl0ads will need to be changed. A migration is an ideal opportunity to host all images and files with a CDN.

6. Minimize Hits to the Database

Why is caching so effective? It reduces requests to both the server for processing and to the database for data. Database operations are very expensive in terms of resources and so you should review your code to minimize hits to the database. COnsider the following:

• Ensure that you minimize the number of connections opened to a database in a visit. Once a database connection is opened, try to perform as many database operations as possible and then close the connection. Do not open and close connections several times unless this is necessary.
• Open database connections as late as possible and close them as early as possible – ie don’t do additional processing that isnt necessary whilst the connection is open, grab the data, close the connection and then do additional processing.
• Review your SQL code to ensure it is efficient – several SQL operations can be performed in one operation and it is not always necessary to execute separate insert and select statements. Ensure you don’t use  Select * in your queries – always select just the columns you need.

7. Optimize Images

Maybe it is just my perception, but I always remember this being first on the list of a site optimization checklist and now it hardly even features in a top twenty. I guess there are more interesting things to talk about, but optimizing images is still a major factor in reducing page loads. Use GIF where-ever possible, screenshots and logos are normally a must for GIF. GIF’s max colors in a file is 256 but you can normally reduce this without compromising quality and reduce the filesize. JPGs should be examined even more closely as they are normally larger files, you can set quality anywhere between 1-100 and normally around 65  is an acceptable compromise between quality and size. Similarly you should optimize PNG files for size vs quality. Photoshop’s Save For Devices tool is invaluable for this purpose.
Also, always use the height and width attributes of the <img> tag as this speed up loading, but do not scale and image using these attributes – these should be the actual image size.

8. GZip Everything

Gzip is a popular compression protocol and about 95% of all web traffic is on browsers that support Gzip decompression. Therefore it is safe to say the all your Http traffic delivered to the user’s browser should be Gzip compressed. Putting  Accept-Encoding: gzip, deflate in your http header informs Apache that the content is Gzip compressed and it will direct that to the user’s browser with an appropriate header to instruct the browser of the content type and to decompress it. Most site’s will Gzip http pages but css and js files should also be Gzip compressed.

9. Reduce the Number of Http Requests

Http requests are expensive as they require round trips to the web server, consider the following to minimize the number of requests:

• Combine files – dont have several .css or .js files unless this is strictly necessary,  just combine these into a single large file.
• Combine images – if you have several images for your site’s design consider combining the images into a single image file and then selecting a segment by using the CSS background-image and background-position properties. The CSS Sprites tutorial on A List Apart is a good tutorial.

10. Examine Your Final Page

This isnt really a separate best practice in itself, but it is probably the most effective way to find page bloat. Too often the optimization is done by reviewing all the sever-side files but when a page is generated there are often new items added to the header which werent noticed or were added by a script that was installed. Starting at the optimization at the final generated page is the best technique. This will also identify html bloat, such as empty tag (empty <span> and <div> tags are infamous for populating pages).

CDN Pricing (March 2010)

*SimpleCDN does not have a separate storage charge, pricing is in plans for a set amount of storage and bandwidth and overages are not allowed (you are required to upgrade to the next plan). The base plan used for this pricing comparison has 2GB of storage and  5TB of bandwidth per month.

Observations:

The first thing you will need to establish is whether to use http progressive download or true streaming. If you are serving images via the CDN or providing downloads (zip files, exe files or media files for download) then http (or ‘progressive’) download is the mode most suitable, if your app streams audio or video to users then true streaming is optimal. Http download simply dumps the max output possible on the user requesting the file whereas true streaming sets up a two way communication between the requestor and the server which allows for optimizing the stream to fit the user’s bandwidth and provides more intelligent features such as seeking to a point in the file (these features do not need to be implemented by the developer they should be available out-of-the-box with most media players).

Amazon CloudFront

If you are using Amazon CloudFront then your starting point will be the Simple Storage Solution (S3) which is the static storage component of Amazon Web Services, to upload your files to S3 from your application you will need to use S3′s REST API although some CMS’s do have integrated S3 upload capabilities (see Using S3 in WordPress). Amazon doesn’t provide a GUI to upload files to so you will need to use a third party tool – Jungle Disk provides upload to S3 although it is more of a backup solution than a file manager,  S3 Fox Firefox plugin as an efficient S3 uploading and file management tool, in addition CloudBerry FileExplorer is a full featured desktop app for managing S3 and CloudFront files.
Any file stored in S3 can be served from AWS’s CloudFront CDN. To use CloudFront you are required to sign up for it separately to S3 (you can sign up here)  Files served by CloudFront must exist in S3 and when a file is requested from CloudFront, CloudFront initially requests the file from S3 and then caches it at one of its edge locations. Once you have an account at CloudFront, login to the AWS Management Console and navigate to the CloudFront tab. Under a single CloudFront account you can have various Distributions which are essential ‘buckets’ of storage which can have different attributes.  Click the Create Distribution button which will open the setup dialog, then select either to use http download mode or true streaming, and associate the Distribution with an S3 bucket.

Once the Distribution is created, you will  be given a unique domain which will look similar to dxabw2ae51eqo.cloudfront.net , to request your files from CloudFront instead of S3 simply replace your S3 domain (in the format bucket_name.s3.amazonaws.com) with your CloudFront domain on all your file URL’s – the file names will remain unchanged.

Other CDNs

There are several other popular CDN’s such as CloudFiles, MaxCDN, SimpleCDN. In essence they work in  exactly the same way – you are required to use a custom API if you want to implement uploading to the CDN from your app or you can upload the files manually and then link to from your app.  Most of these provide an online file explorer which allows you to upload and manage files although there is not the same number of third party file management tools as for S3/CloudFront.

If you are using WordPress you can use several plugins to facilitate file serving from a CDN , notably W3 Total Cache  allows you to specific any CDN to serve files from. CDN Tools is  a plugin dedicated to the CloudFiles CDN which provides very tight integration between the WordPress file upload and the CDN.

See our CDN Pricing Comparison for pricing details.

• Pingdom : This would definitely fall under the basic tools category and is a tool for both cloud and dedicated servers. Pingdom simply checks that that your site is up and running and will email or SMS you if the site is down. In addition Pingdom will monitor the response time of your site although there are no triggers to alert you if the response is longer than a pre-set period.
• CloudKick : CloudKick provides complete monitoring of your cloud server’s Disk, IO, load, CPU, bandwidth, memory and presents it in a user-friendly dashboard. In addition it provides  a powerful API to write custom performance logs and tests. CloudKick is compatible with most cloud servers including Rackspace, Amazon, GoGrid, SliceHost.
• ServerDensity : ServerDensity is a monitoring tool which monitors the server’s load, running processes, disk usage etc. A key advantage of ServerDensity is that it provides server snapshots – very often when there is a problem with the server it may have disappeared by the time an admin comes to diagnose and fix the issue. Snapshots allows the adminstrator to review the exact state of the server as of the time when the issue existed.
  ServerDensity is compatible with all Linux based cloud servers as it requires the installation of a small daemon (which should be a very simple process) and then the  ServerDensity hosted service monitors the diagnostic information sent by the daemon.
• CloudTest - CloudTest provides a detailed monitoring tool similar to CloudKick and ServerDensity, however in addition to the monitoring capability CloudTest provides browser based testing of html/AJAX web applications. Through a browser based http or https recorder , system testers can record and then run a test on the web application and receive diagnostic information on the running of the test.

• Scale - This is probably the biggest single advantage of cloud hosting, scaling up beyond a single server is notoriously difficult on a dedicated server setup – load balancing, maintaining sessions across different machines and a host of other issues make scaling up very tricky.
  Cloud hosting by comparison allows painless scaling by spinning up more instances as required, instances can be programatically spun up and destroyed as required meaning the application can handle all the scaling without need for intervention. In addition to writing custom code, third-party products such as RightScale can sit on top of a cloud hosting instance and automatically implement all the scaling.
• Cost - Dedicated hosting still has a pricing advantage for small installations. A single low-spec (2GB RAM, 160 GB Storage, 2Ghz single-core CPU) dedicated server will cost about $130 per month for dedicated hosting, but this usually comes with a huge amount of bandwidth (2TB per month on Server Beach for example).  By contrast, cloud hosts charge a little less for the ‘hardware’ – a similar spec’d server at RackSpace Cloud Servers costs about $90 per month, however bandwidth is usually charged between $0.11 – $0.14 per GB , so if your users will require a lot of bandwidth cloud hosting can work out more expensive (although it should be noted, if you are using a lot of bandwidth you should be using a CDN)
• Requirement for OS/Hardware Access – A major drawback of cloud hosting is the lack of access to the operating system and/or hardware. If you need to fine-tune the software/hardware stack then dedicated hosting is the only way to go.
• Security - Theoretically a cloud server should be less secure than a dedicated host, if your ‘instance’ is part of a cluster of machines that will inherently be less secure than an isolated machine which has fewer connections. However, against this must be weighed the fact that cloud hosts will (or should!) have a dedicated security team to patch the OS when necessary and implement security best practices which will often not be fully adhered to if you have to manage the security of a dedicated host yourself.
  In practice, the greatest vulnerabilities are usually at the application level which is independent of the platform.
• Simplicity - Cloud servers are far simpler to administrate than dedicated servers, adding servers can be done via a control panel and all the OS patching is fully managed.
• Reliability – There is no definitive winner here, cloud servers have built in failover so you will not notice a hardware/server failure. However it should be remembered that a cloud host is actually in  a cluster of servers which you share with other users, severe slowdowns can occur from the other users running long running queries on the cluster.

So cloud hosting stacks up very well against dedicated hosts and if you run a simple application such as a CMS powered website then a cloud host is almost certainly the right choice, however if you need a very specialized solution then dedicated hosting (or co-lo) can still be the best choice.

• Hosting images on a separate domain speeds up site load times as most browsers can only make two simultaneous requests to a domain. Thus if all your file are on a single domain the requests are queued and handled two at a time which slows the load time.
• Moving hosts is easier if the file locations do not change (a major difficulty in changing hosts is downloading, then uploading all the images and finally changing all <img> the references in your articles).
• If the files are on S3 it is very easy to transfer them to Amazon’s CloudFront Content Delivery Network (CDN).  CloudFront will give an additional performance boost for user’s who are located geographically far away from your server as CloudFront caches the files in 14 locations around the world.
• If you are approaching your hosts storage limit then using S3 will probably be cheaper than purchasing additional storage space on your host.

The S3 for WordPress plugin modifies the standard WordPress image upload dialog to upload the images to your designated S3 bucket, from there uploading files to S3 is seemless as it is the standard file uploading process.
You will of course require an S3 account, and you should add a separate ‘bucket’ for file storage (buckets in AWS are similar to directories).

CloudFront in WordPress

Any file stored in S3 can be used with AWS’s CloudFront CDN. To use CloudFront you are required to sign up for it separately to S3 (you can sign up here)  Files served by CloudFront must exist in S3 and when a file is requested from CloudFront, CloudFront initially requests the file from S3 and then caches it at one of its edge locations.

Once you have an account at CloudFront, login to the AWS Management Console and navigate to the CloudFront tab. Under a single CloudFront account you can have various Distributions which are essential ‘buckets’ of storage which can have different attributes.  Click the Create Distribution button which will open the setup dialog, where you choose whether to use Download (for images) or Steaming (for video) and associate the Distribution with an S3 bucket. Once the Distribution is created, you will  be given a unique domains which will look like dxabw2ae51eqo.cloudfront.net , to request your files from CloudFront simply replace your S3 domain (in the format bucket_name.s3.amazonaws.com) with your CloudFront domain on all your file URL’s – the file names will remain unchanged. Unfortunately the S3 plugin in WordPress only works with S3 and you must manually change the file URL’s after uploading although a global find/replace plugin can be used for this.

PageSpeed – This is Firefox addon from Google which can run automatically on all page loads or on-demand. It provides very detailed analysis on the page load and grades the page on its adherance to best practices (eg using compression on javascript files). This tool supercedes the YSlow Firefox addon from Yahoo, the information is extremely detailed  but can become a bit overwhelming.

WebPageTest – This is currently my favorite testing tool, it is an online tool where you input your URL and then the test page refreshes with the performance test results. The results include both the ‘waterfall’ graphic of load times for the page components and a grading of the adherence to best practices. There isn’t the same information overload as with Google PageSpeed and it offers the ability to test the load speed from five different geographic locations (which can help test if your CDN is working for you) .
WebPageTest crucially allows loads to be tested on different browsers, this is a great addition as browsers vary in their ability to load page resources simultaneously which can have a dramatic impact on the page load time.

Pingdom Load Test – Pingdom offers a very robust website monitoring service but it also offers a free page load test tool. This is a very simple tool which can be quickly run to determine the speed of the components in a page load. This tool runs a little faster than the WebPageTest tool but has few of its features.