Here’s a little about my experience moving the hosting of this WordPress blog to the Azure platform.
I had been using Webcity to host this blog for many years. I would constantly receive warnings about CPU spikes from them because their solution doesn’t scale. This led to my account being suspended a number of times this year and in one week last month there were 2 x 8 hour+ unexplained & un-communicated outages for all hosted websites – this pushed me over the edge to look at other solutions. I liked the idea of more stable infrastructure and the flexibility to scale up and down.
Webcity charged me $150AU per year. Using CPanel, I worked out that my total HTTP traffic per month averaged over the last 6 months is 6GB per month. Based on the Azure pricing calculator (http://azure.microsoft.com/en-us/pricing/calculator/), this means I should actually be saving around $30 per year by using Azure.
To get started, I logged onto https://manage.windowsazure.com and associated my credit card with my existing Windows Live ID (or whatever it is called now). From there, I simply opened the Azure management website, went to Web Sites, Create a Web Site and then From Gallery:
Selected WordPress, then filled in the site details:
On the next page, accept the new Database name or create your own.
After a few minutes, the new website will appear and go into ‘Running’ status. Select the instance and click ‘Browse’:
Fill in your details, these are only temporary as you can change them later. Hit ‘Install WordPress’. After a few minutes there will be a success page.
A basic WordPress site is now up and running, you can visit the URL that you chose at the start – in my case it was http://danovich.azurewebsites.net/ .
The default option is to set up the web hosting plan as ‘Free’, however this doesn’t allow for a custom domain name (danovich.com.au).From the help page: Each plan has a mode associated with it. Different modes expose different sets of features and capabilities. Plans in the Free and Shared modes run on a shared infrastructure with sites managed by other customers. These sites will have strict quotas for resource utilization. Plans in the Basic and Standard modes run on resources that are dedicated to your sites and have fewer restrictions. Also see http://azure.microsoft.com/en-us/pricing/details/websites/To configure this, head back to the Azure management portal, select your website and click on ‘Scale’. In my case I selected Shared, this will be enough for me for now and the beauty of Azure is that I can upgrade to a different plan easily later on if needed.
I originally planned to use a migration tool to move across the site configuration and content however I ran into multiple errors no matter which migration tool I tried:
All-in-One WP Migration
WP Clone by WP Academy
WP Migrate DB
I put this down to the fact that I had a very old and unsupported WordPress theme running plus 6+ years of WordPress customizations. I decided not to use the migration plugin tools and went for using the freshly installed WordPress instance on Azure, picked a new theme, added a handful of useful plugins and then used the native export and import functionality of WordPress to get the old posts across. I then used FTP to copy to uploads directory across.
I remembered that my DNS was hosted with my old web hosting provider, so I upgraded my domain registration provider account to also host by DNS. I entered my handful of A and CNAME records and waited til the next day for replication around the Internet. At the same time, I added an additional A record for migrate.danovich.com.au that pointed to the IP address provided by Azure (screenshot below) and also a CNAME for awverify.migrate.danovich.com.au to point to awverify.migrate.danovich.azurewebsites.net for the purposes of testing before cutting over the remaining DNS records.
After waiting for replication, I went into the Azure management portal –> configuration –> domain names –> manage domains, where I added the new line for migrate.danovich.com.au. I could then use my browser to see that migrate.danovich.com.au was now showing my new website hosted on Azure. The next step was to update my remaining A & CNAME DNS records to point to the IP address or the awverify CNAME that Azure needs for verification.
Once this was done, I could access the website using blog.danovich.com.au or any of the other DNS entries I had added.
Whilst it was very easy to set up a WordPress instance on Azure and relatively easy to import my old content, I’ve had a few issues using Azure – specifically around billing and availability – to the point where I don’t see me continuing to use Azure in the future. I’ll save that for another post…… but overall it was a very easy process to get WordPress up and running on Azure.
After a recent move to Azure, I was doing some performance testing for this blog via gtmetrix.com. My reports were suggesting to ‘leverage browser caching’ and ‘add expires headers’ to improve my performance gradings.
This is usually straight forward to implement; it is simply a few lines added to the sites .htaccess file – either manually or by one of the many WordPress plugins that will update it for you:
Even after this was implemented, I noticed that it wasn’t making any difference to my performance reports – which got me thinking about Azure and that it would be running IIS in the backend and not Apache – and of course IIS doesn’t use the .htaccess file, it uses web.config instead.
After reading a few articles about translating .htaccess content to web.config, I was ready to go. Using FTP, I edited the web.config file in my root directory and added the following lines:
The configuration forces files to be cached on the client side for 28 days and 28 days on the server side except for .php files, which is only 1 hour. I re-ran the performance grading reports and received a much better score!
I can never find the generic Cisco Visio icons when I need them – the product specific ones are well documented on the Cisco support website – however the generic ones that I often need for logical or conceptual diagrams always seem hard to locate. So I’m posting them here so I can find them in future and to help out anyone else who needs them – I don’t believe there are any restrictions on their distribution.
Recently while cleaning up my WordPress database, I noticed that the wp_wps_logs table was over 470MB in size. After a bit of research, I realised this was due to an old plugin that I once used – iThemes Security (formerly Better WP Security). I no longer used this so I needed to get the database size down.
Through cPanel, I opened myPhPAdmin. On the left I navigated to the wp_wps_logs table then clicked on the Operations tab in the top right. Scrolling down to the bottom of the page, there is the option to Empty the table (TRUNCATE). Once I truncated the table, my database size was down to about 20MB!