I have mentioned earlier on my blog that GoDaddy is my hosting provider and how living inside a shared hosting environment was affecting my blog’s loading time because of higher traffic. In that same blog post, I also mentioned how thing’s had reached a point where I was considering switching to virtual dedicated servers or grid hosting – but I left that decision off for another day. As a stop-gap measure, I tackled the problem by reducing the number of plugins that pre-process pages before serving them on my blog. That’s the story thus far.
Firstly, one of the major reasons why I was reluctant to shift was that my hosting account is paid for till 2012 – and it just seemed to be a waste of money to abandon it and upgrade to a VPS host. I surely wouldn’t have left any of the sites hosted here behind in case I was shifting to a new server, so what would I do with my shared hosting account then?
Secondly, VPS hosting services usually cost around $20-25 per month (well, at least the reliable ones do) and at the same time, GoDaddy was offering a beta test of their new Grid Hosting service at $5 per month. I was sorely tempted to take that offer, I must admit. I searched around on the Internet, and sadly most of the search results that showed up were either affiliate links to GoDaddy’s Grid Hosting Beta sign up page, Todd Cochrane praising it on behalf of his blog’s sponsor (GoDaddy – no surprises there) with a promise to try the service out (never materialized, as far as I see), curious souls inquiring in forums as to whether anyone else had used it, and a few horror stories. I wasn’t willing to jump the gun and pass judgement on a beta service that I hadn’t tried. I let it be for then.
Fast forward to now. I have been using GoDaddy Grid Hosting for close to two months now, and I wanted to share my impression of it thus far. There is a serious lack of reviews from actual customers of the product on the Web. I hope that this post will be one of the many opinions on offered on the product as more customers start using it – for better or worse.
What is ‘grid hosting’, and why are hosting companies offering such services now?
Allow me to give a brief explanation to those who are new to this; you can skip to the next heading in case you don’t want a lesson on the basics.
A normal shared hosting environment has a single server machine where hundreds – sometimes thousands, depending on which company is your host – reside. All of these websites share a single IP address as they are on the same server. When a browser sends a request to your website’s nameserver, the hosting company resolves it internally at their end and serves up your web page from that particular server.
This setup works fine for most low traffic websites – and for ‘static’ websites that load HTML files that do not change. Until a few years ago, this is what most websites used to be so shared hosting worked fine for a large population of websites. Most websites these days though are ‘dynamically’ generated either by custom-coded scripts, or increasingly popular content management systems like WordPress. What WordPress does is that it stores your content in a database, then every time a visitor wants to view your website it checks what sort of styling to use (from your theme), any sort of processing done by plugins (converting links to YouTube into embedded videos, for example), converts the end result into an HTML file and sends it to the visitor’s browser. All this happens within seconds.
But. Let’s say your website starts getting a more steady stream of visitors or sees a sudden spike in traffic. Your web server now has to process more of these page generation requests in real-time and dispatch the generated HTML file. (To some extent, this can be countered by using ‘caching’ plugins that temporarily store the result of database calls and/or generated HTML files and use that to cut down user load times.)
In a universe where your server has infinite computing resources, this wouldn’t matter because the server would have infinite computing resources at its disposal. Unfortunately, the economics of reality dictate that a single machine can only handle so many requests before giving up the ghost. And this is particularly true of shared hosting these days: any single website is allocated only a small chunk of computing resources on the server, and even then heavy traffic to a completely different website on the same server can cause bottlenecks that slow down everyone else. Indeed, a ‘rogue’ website could cause a server to crash, taking down the hundreds/thousands of websites on the same server along with it. (Usually, hosts don’t let this happen; opting instead to kill of your site if it starts putting extra load on its servers rather than risking downtime.)
With an ever-increasing number of websites taxing single server setups, shared hosting companies these days have been under fire from customers for slow loading times. The traditional method to deal with these issues has been to invest in more servers and make lesser number of websites share the same server. That way, each individual site gets a greater than (earlier) share of resources and – hopefully – functions faster.
Grid hosting is a new approach being adopted by companies such as MediaTemple (they’re the first ones to commercially offer such services on a mass scale, I think) – and now GoDaddy – to solve this problem. The idea is that instead of your site’s data living on a single machine and being subjected to the limits of that single machine, your data is mirrored across multiple machines. When a browser request to view your site is received by the host, a set of load balancing servers forwards the request to one of the many servers where you data lives. This way, in case your website – or any other website – suddenly receives a large amount of traffic, the load can be distributed. By using a divide and conquer approach, a single website theoretically cannot take down others with it. Another advantage is that if one server is taken offline for maintenance, your website need not have to go offline because copies of it still exist on other machines.
You won’t commonly see grid hosting services offered since the technology is still in its infancy. It has been made economically possible at a mass scale by recent advances in cloud computing. MediaTemple, the pioneer of this concept, rapidly gained a lot of customers on the premise of greater reliability and a few years ago, it was the darling of many bloggers. Things soured when technology didn’t live up to the hype and many sites suffered greater downtime. One of the major glitches with grid-hosting services across the board has been how to implement scaling with MySQL databases. Because of the nature of the setup, MySQL databases in grid hosting environment often live on a different server(s) compared to a site’s file store server; quite often, it was turning out that database fetches were a bottleneck. MediaTemple itself acknowledged the problem by starting development on a new setup they dub mt Cluster Server – slated to eventually replace their Grid Server offering.
Why switch to GoDaddy Grid Hosting now?
Until a few months ago, the only way to shift to GoDaddy’s Grid Hosting beta service was to sign up for a new account (= pay again for that new account), then shift all files and database over manually. Then, GoDaddy started offering automated upgrades to grid hosting beta – only if there were no active databases associated with your account. If it did, you were required to delete them from your account and restore them once the automated upgrade was done.
GoDaddy’s Grid Hosting service is now out of beta. I was surprised to learn from one of their representatives on Twitter that all new GoDaddy hosting accounts are actually ‘grid’ accounts. They had also started offering automated upgrades all accounts – regardless of database usage associated with the account. As a major web host with millions of customers, it must have taken a lot of courage on their part to make such a drastic change! The more I thought about it, the more likely it seemed that they really believed their offering was ready for prime time. After all, a broken system would only increase their costs in terms of having to handle a larger number of customer support requests (and bad publicity).
The horror stories from previous customers (when it was in beta, mind you) did play on my mind. Still, I decided to take a leap of faith two months ago. With loading times as they were on my account, I reckoned that there was no way I could go downhill from there.
The automated upgrade took about 24 hours to take effect, during which the sites hosted on my account didn’t go down (although my access to hosting control panel was cut). Once the switch was done, I didn’t have to make any changes manually nor were there any major ‘obvious’ problems such as sites not loading at all. I was apprehensive that something might have broken as the absolute file storage path of the associated hosting account gets changed during the move, but that ultimately was a non-issue.
How does GoDaddy Grid Hosting measure up?
Right off the bat, sites seemingly loaded faster. I asked a few people and they felt the same. This, however, is a subjective assessment: the mere suggestion of a ‘faster’ server might bias opinions to page loads ‘feeling’ faster. I compared some statistics instead to check whether it was indeed faster.
I started off with a simple test – using YSlow for Firebug. Taking care to switch the measurement rule set to ‘Small Site or Blog’ to measure the performance before and after the switch. Using the normal metric for large sites, this blog was given grade ‘C’ by YSlow; after the switch to ‘blog’ ruleset, the grade jumped up to grade ‘A’. You can try out the test yourself, if you’re curious. You’ll notice that the low scoring sections within the test are caused mostly due the usage of ad servers.
Next, I measured the page loading time using Pingdom’s excellent page load analysis tool. Unlike many other similar tools that simply record the response time, Pingdom’s tool measures actual page load times as users experience it, including media downloads.
The above graph shows the response time recorded by Pingdom for my blog for the past six months. You’ll notice that despite the spikes in the graph, on average the response time stayed pretty much the same. Does that mean that my blog loaded equally fast throughout? No. Response time is a metric that’s useful, but not for this analysis – as it merely tells the time the server takes to send an acknowledgement response to the first request sent by a browser.
Using the Pingdom’s page load timing analysis tool that I mentioned earlier (as opposed to response time analysis), I measured the actual page load times. In my case, the total page load time came out to 2.49 seconds after the switch to grid hosting. Previously, it used to be around 15 seconds, so that’s a big improvement! I’ve repeated the test on multiple occasions, and the result unanimously seems to be that site loading is faster after the switch to grid hosting – and by a significant factor. Your mileage may vary depending on where/when you’re testing from.
It appears then that page loads are indeed faster now. But how does grid hosting hold up under increased traffic load? To test this, I used Load Impact’s load testing tool. What this does is that it simulates the effect of multiple visitors requesting the same site at the same time, and measures how the server performs. I only have a free account on the service, so I could only carry out their 50-client test. The statistics are quite revealing.
Load Impact starts off with 10 simulated clients simultaneously sending a request to the server, scaling up the number of clients in steps to the maximum limit (50 in my case) as long as the server can cope up. As you can see, at the start of the test the actual page load time is 10 seconds but as the test progresses, the performance degraded to 15 seconds. You can’t see it on this graph, but at 50 clients the test had to be aborted because the server couldn’t keep up with the requests any longer.
Now, look at the same test run on my blog after the switch to GoDaddy Grid Hosting. Right at the start, you can see page load time is lower – close to the approximately 3 seconds measured by Pingdom. As the number of clients increases, the performance remains consistent; in fact, evening hinting towards a downward trend. This time, the test completed successfully with a maximum load of 50 clients simultaneously hitting the site. This doesn’t seem surprising, as GoDaddy’s own documentation notes that in the legacy hosting environment the maximum number of simultaneous client requests supported is 200 (on the costliest plan) while for grid hosting the same figure is up to 600 simultaneous connections. While this varies depending on what plan you are on, at the very least your allowance is increased to thrice of what it was earlier. It’s interesting to note that in the legacy hosting environment, the load test had to be aborted at 50 clients – a figure much lower than the ‘maximum’ limit for my account then.
For better understanding of how Grid Hosting performs, it would obviously be better to repeat the test with a higher number of concurrent client requests. Unfortunately, I can’t do that with my free Load Impact account. Nevertheless, the hint of a downward trend – if it holds up with greater traffic – shows that the grid cluster does indeed in real-time detect traffic spikes and compensate accordingly. Possibly, load getting distributed across multiple machines during a spike could lead to the lower page load times.
What about downtime? How reliable exactly is GoDaddy? Heading back to Pingdom, once again, I checked what the data has to say. The way Pingdom checks whether my site is up or not is to send a request at regular intervals and monitoring whether (and how long) the server takes to reply. Pingdom is sweet enough to the tell the IP address(es) they use for this test, which makes it a cinch to exclude its visits from visitors analytics. Before I show the graphs, note that my Pingdom account is set to send a request every 5 minutes; thus, the precision of the data below is limited by that. For instance, if the real downtime period during any given occurrence was 13 minutes, Pingdom will only find out at the 15th minute that the site is back up on its next check. Keep this granularity of data in mind when analyzing.
The data shows that on average GoDaddy has given me an uptime of about 99.2% over the past six months. Even though there have been outages, as expected on any host, they have occurred through small, cumulative incidents rather than any single long one. As such, the chances of visitors noticing are negligibly small, in the larger scheme of things.
However, drilling into the data for the past month shows that uptime has gone down to 99.76%; also, in the timeframe of past six months, almost half of the outages occurred in the past month. I set email alerts for downtime, and looking through those it seems that while earlier the outages used to be 10-15 minutes long after the switch to grid hosting they are mostly just 5 minutes long (except for one long 20 minute one) but at a greater frequency. It could be possible that those ‘5 minute’ or ’10 minute’ outages were actually shorter; as I explained earlier how the pings are carried out only at five-minute intervals. If they are indeed shorter, then that would imply a higher uptime in reality. Maybe someone with a more frequent ping test will be able to shed some light. As a customer, I am satisfied so far with this reliability. The tiny downtime periods don’t mean much on a personal blog. Your site’s requirements might be different though.
Moving on to memory usage / CPU cycles, I am not sure on what metrics to use to compare the performance. I’ll go ahead and mention anecdotal evidence instead, which may shed some light. I use Gallery2 photo gallery software on my hosting account, on which certain interactions can be considered as ‘intensive’. (I know it sounds laughable, but when it comes to shared hosting accounts that’s probably the closest you’d come to ‘taxing’ your account.)
In GoDaddy’s older hosting environment, I couldn’t add more than six images at one go to any album. Let me clarify that statement – every time you upload pictures or ask Gallery2 to check a folder on your server for new images (the usual way I add pictures), it adds the images one-by-one while creating thumbnails for them during the process. Every time I did this in the old setup, the process would time out after importing roughly six photos. I assume this has something to do with the script execution time limits that GoDaddy had that. Sure, you can increase it using php.ini settings but I don’t think GoDaddy allowed any scripts that took more than 30 seconds to execute to stay running.
There is a marked difference in the grid hosting setup with this. I have successfully imported close to 200 photos in the same import session – with all thumbnails successfully generated too – without a hiccup. Gallery2 displays the amount of memory being used for the operation, which is currently shown as 128 MB during the operations; earlier, it used to be 32-64 MB. While no longer shown on the current web hosting packages page on GoDaddy (essentially grid hosting, since that’s the default setup now), when it was in beta I distinctly remember that GoDaddy mentioned grid accounts can use ‘unlimited’ CPU cycles. Take ‘unlimited’ with a pinch of salt; though, for most purposes the grid setup will allow you to execute longer-running scripts with greater memory allocation.
Did you face any problems after switching to grid hosting?
Yes, I did. Going back to my Gallery2 install, I noticed that after the switch, thumbnails stopped appearing on gallery front page. (I use a plugin that switches album thumbnails randomly to a different image, to keep it visually different.) Before the switch, I was using ImageMagick along with jpegtran (the latter for editing operations such as cropping, rotating, etc – where it’s useful as it supports lossless JPEG file saves), both taken from the pre-installed paths available for hosting accounts. For future reference, the paths to them are:
ImageMagick (v6): /usr/local/bin/imagemagick
jpegtran: /usr/bin/jpegtran
Both worked fine with my Gallery2 install in the shared hosting environment. In grid hosting however, Gallery2 encountered errors using them despite the fact that it detected those paths were valid. I switched the image toolkit used by Gallery2 to GD instead, and now everything works just fine.
Apart from this, I faced no other problems. I did carry out one further modification. I already have gzip compression enabled for web pages served on my blog. Gzip compression compresses web pages before dispatched from the server in case the capability is supported by a browser (true for most modern browsers). It reduces bandwidth usage and makes page loads faster by reducing the amount of data to be downloaded to display the page. For blogs showing many pages on the home/landing page, it’s quite handy. Gzip compression can be done by adding the following line of code right at the top of your PHP files (before DOCTYPE):
<?php if (substr_count($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) ob_start("ob_gzhandler"); else ob_start(); ?>
After the switch to grid hosting, I also decided to enable Zend Optimizer support on my account. Zend Optimizer increases security, by obfuscating PHP code used on a site with Zend Guard; basically, it makes your code a tiny bit more secure by hiding the actual code being executed by your server. Zend Optimizer is pre-installed on GoDaddy servers and can be enabled in your account by adding the following lines of code to the php.ini file in your account:
[Zend] zend_optimizer.optimization_level=15 zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.3.3 zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.3.3 zend_extension=/usr/local/Zend/lib/Optimizer-3.3.3/ZendExtensionManager.so zend_extension_ts=/usr/local/Zend/lib/Optimizer_TS-3.3.3/ZendExtensionManager_TS.so
Zend Optimizer comes with an extensive user guide that you can use in case you want to play around with the settings defined by the code above. Note that version pre-installed is a slightly older version, but for normal usage that’s okay.
In case you do specifically need a newer version of Zend / ImageMagick / any other library, you could always place the binaries in a folder in your own hosting account and point whatever application that needs it to that particular path.
Would I recommend GoDaddy Grid Hosting?
While it is early days yet, if the current level of service continues I would say “yes” to the above question. GoDaddy seems to have overcome the teething issues its beta grid hosting service had, and gone on to implement it successfully in a production environment. Existing customers need not worry about having to adjust to a new control panel either, as the one used for grid hosting is identical to legacy shared hosting.
GoDaddy has had a bad reputation as a web hosting company, but I haven’t had any bad experiences so far. More often than not, it’s a case of customers expecting too much from economical shared hosting. Many first-time webmasters only look for storage / bandwidth offerings, assume GoDaddy is a good deal, and then howl when traffic / resource intensive sites work sluggishly on it. At least GoDaddy has clearly defined policies on the actual parameters that affect account performance such number of concurrent client requests allowed – something that not many other popular shared hosting companies are forthcoming about.
One popular complaint has been that GoDaddy’s custom control panel doesn’t offer enough…control. I whole-heartedly agree that was indeed that case two years ago and I’d have preferred to use CPanel instead in those days. Now, however, the upgraded custom control panel that GoDaddy has gives access / customizability to pretty much everything that a CPanel setup would offer – and in a cleaner interface. Facilities not offered earlier (SSH access, for instance) are now offered and have been available for many moons now.
Another ‘feature’ added by GoDaddy (sadly, available only for new customers) is the choice of geographical location for the server farm your account will belong. Now you can choose between US (existing Scottsdale, Arizona farm), Europe (based in Netherlands), and Asia (based in Singapore) as the location for where you want your account to be. The advantage is that if you / majority of your visitors are from Europe / Asia, you can choose a server that is physically closer to them – and thus faster site loading times / greater reliability of site availability as browser requests don’t have to travel a greater distance. It’s a small thing, but during instances such as when undersea cables off the coast of Egypt got severed, hampering access to US-hosted websites from countries like India, having a server physically closer to where most of the visitors are means your site will be accessible even when many others are not.
Steps such as these show that GoDaddy is indeed listening to customer feedback and taking steps to improve its offerings. When Google announced its release of mod_pagespeed Apache server module, GoDaddy was one of the first and largest web hosts mentioned who are working on implementing it (although Dreamhost did show them the middle finger by implementing it first). GoDaddy is extremely proactive in providing support to distressed customers through social media, and even when contacting their tech support via email I’ve never once had a problem with their service.
I mentioned earlier that I gave thought to switching because my sites were slowing down on this account. Having already invested into this account was a deterrent, but if things got worse I’d have been compelled to cut my losses and move on. The question is – if I did move, then what do I go to? I was apprehensive of MediaTemple because I’ve heard stories of its Grid Server plan being unreliable, and if I shifted to another shared hosting provider, what was the guarantee that it would work any better in comparison?
Overall, a big thumbs up to GoDaddy Grid Hosting from me. It seems that finally there’s a grid hosting offering that just works – and that too at standard shared hosting prices rather than a premium. If you’re a Grid customer too, I’d love to know what your experience has been. Do leave a comment / link to your own take on it below!
Disclaimer: None of the links listed in the post are affiliate links, although you will find banners ads from GoDaddy (if you don’t use AdBlock already 😉 ) on this blog. Still, if you decide to sign up with GoDaddy, found this blog post useful in making that decision, and want to thank me for it here’s an affiliate link to sign up for GoDaddy.com Hosting Plans.