ASchroder.com

It’s been a while since I have done any of my Magento Hosting Reviews but I’ve finally gotten around to reviewing Crucial Web Hosting. Ages ago (I mean months) a reader specifically requested I review Crucial for their Magento hosting capability, and they were very keen to participate.

Crucial have gone ahead and pre-installed Magento on one of their split shared hosting programs. I’ll talk a little about what that means during the review. Crucial have also kindly offered to keep their Magento demo install up and running so that you guys can try the Crucial Magento demo out for yourselves.

In this Magento Hosting review, just as with my others I’ll be looking at the hosting proposition itself, the value and the price and how they stack up. I’ll also look at the responsiveness of their data centers and comment on the general access levels the hosting provides.

I noticed that my last Magento Hosting Review became a bit of a monster and probably put a lot of people off because it was too long and not that well structured. This time I’ll try and give the whole review a little mini-index so that you can jump to the parts you actually want to read about, if you are not interested in the whole thing.

• The Hosting
• Hardware
• What does split shared mean?
• How does the value stack up
• The Performance
• Ping Tests (Latency)
• Page loads (Server Power and Magento optimisaztion)
• General responsiveness
• Access and Support
• Conclusion

The Hosting

In this section I’ll discuss the actual hosting solution offered by Crucial. I’ll look at the hardware they’re operating, explain the notion of split-shared hosting and how that relates to other shared hosting solutions. I’ll try to weigh up the offering with other similar solutions for value.

Right off the bat the hardware offering is definitely high-end. The Crucual website claims “Quad Core Intel Xeon Harpertown 3.0 GHz, 32 GB DDR-2 RAM, 15K.5 RPM hard drives, and a Gigabit uplink”. I checked this out on the command line and sure enough 8 3GHz processors from cat /proc/cpuinfo! A look at the output of top on the box reveals the beast is hardly even raising an eyebrow at the work it’s doing, an avg 0% cpu usage and over half the RAM is free. Although this is a shared hosting solution, it is definitely not a machine that is being over worked or put under any pressure by too many clients having to share the same hardware.

Split-shared hosting is a way to divide up the available computer resources (the hardware) among more users without having to share the resources with so many people.

In a traditional shared hosting arrangement all of the users on a server are in the same ’system’. That means they are basically all users on the same Linux box. If everyone is playing nice then there’s not too much of a problem with that. Provided the host is not overselling. The problem is that with so many clients on a box, if one of them has security problems, or get’s ’slashdotted’ then the entire system is put at risk.

With split-shared hosting the single Linux box is virtualized into several small Linux boxes. Each is not a real server, but a virtual one isolated from the others by a special underlying piece of software. Each virtual server has it’s own allocated resources which means that if someone in a neighboring virtual server is slowing a server down, it will not affect your virtual server.

Does this really help? Well, yes and no, there is much less chance that you’ll be affected by the shenanigans of one of the clients you share with, when there are fewer of them, but you are fundamentally still sharing a server with others and exposed to the problems that can accompany that. So it’s better than pure shared hosting, but still no match for a VPS or an actual dedicated server.

Now that we know how the hosting works and how grunty the servers are, what do you get for your money? For $25/ month (less if you pay in advance) you get 50GB of bandwidth and 5Gb of storage space. With ecommerce I always think that if someone is doing 50GB of bandwidth they probably have tens of thousands of visitors and should be making enough sales to warrant a much bigger hosting solution, so bandwidth is probably nothing to worry about. With disk space, 5 gigs is probably more than enough for most webstores, even if you used ultra high-res product photos (say 300kb) and had 3 such images per product, that would be 4500 products (with leftover for the actual Store install etc). In general for small Magento stores the disk space and bandwidth will be adequate. For larger ones, do not look at shared hosting!

To put the price in context, for the same monthly amount you could get the SIP account from Nexcess which in my review I do really rave about. How does Crucial’s Magento hosting option stack up in the performance stakes against Nexcess’s Magento optimized SIP? Read on

The Performance

I normally look at page load time and latency when deciding how well a Magento host performs. To test latency I use the free and excellent service just-ping.com. The results of the test against the Crucial Demo server show that the ltency to large parts of the world in in and around that 100ms sweet spot. Us poor antipodeans in NZ, Aus and SA get a bit slow communication, but hey, no-one cares about that right?!

The Watchmouse service is excellent for looking at page load times. I have run the tests and the results are shown below:

WatchMouse test results for the Crucal Magento Demo

And here is even more!

Even more WatchMouse test results for the Crucal Magento Demo

What’s interesting is that even though this is a shared host and there is no advertised performance optimizations carried out on the Magento install, the response times are snappy (around or under 1 second) in most places the tests are run from. That’s really good to see, and if you actually browse around the demo you’ll get a feel for how punchy the pages show up.

Access and Support

Of all the hosting companies I have dealt with I’d have to say I have never had any real problems with the service. Crucial is no exception, the contact I dealt with at Crucial has been polite and really helpful, setting up Magento and installing sample data, responding really quickly to emails and tickets and generally being the good host everyone says they are.

The server access is top notch as well. SSH access is granted by default, and the initial support ticket had all the access details required. Anyone who has approached me for Magento installation help/advice will know that as soon as someone tells me they only have cPanel or (far far worse) only Plesk access, I normally run for the hills and advise others to do the same. As far as I am concerned if you are serious about running a webstore and you want at any time to get a professional involved in support or customizing your store, you need to have the ability for them to access your server using SSH.

Conclusion

Geez this is really tough for me to say! On paper I’d say Nexcess’s SIP looks the better plan for the same money, it’s been optimized for Magento and offers slightly more value. But, I’ve tried out the Crucial demo, I’ve looked at Crucial’s server and I have to say it is as fast or faster, the support is great and I can’t really fault them either. In the end it will probably come down to preference. Both companies offer a money back first month, so perhaps you should sign up for both and decide for yourself based on your interaction with their support and sales team!

PS: As with my other reviews I’m inviting feedback from my readers on personal experiences with the hosting company, because often (as was the case with Simple Helix) the negative experiences that come out of the woodwork can be a real influence in the hosting choices we make.

After some initial Google Base problems with Magento 1.3.2.1, I thought everything was going to be fine, only to get whacked with this error: Expected response code 200, got 403 Service forbidden: Account not registered for Google Base. I checked and checked again that my email/password was right, and that the Google account was registered for Google Base.

There wasn’t much help surfacing on Google for it, so I thought now that I have sifted through everything and looked at various sources, I’d compile a bit of an explanation and help guide for it. Please note this only affects 1.3.2.1, it is fixed in the newer versions of Magento, so unless you are wed to your current version, upgrade!

I posted a forum message on the Google Base boards and got this helpful reply:

• verify the application is not exceeding the api
  limits of approximately 5 requests per second;
• verify the proper uri is being used for the request.
• verify all the required attributes and proper values
  are being used for the item-type being inserted –
  check that all the rules for the item-type are being met.

Given my products were not anything special, I doubted the last option. Also given others were reporting success with the Magento Google Base capability (once the initial problem was fixed), I assumed it wasn’t the 5 requests per second problem either. So what was wrong with the request URI?

Well, to cut a long story short, it seems that my problem was due to the account being used for Google Base, also being a Google Apps account. If you’re interested in the details check out the login options for the Google Account API. The hosted Google Apps account did not have Google Base, but the Google account (with the same email and password) did. The login was succeeding, but then the account that was logged-in did not have access to Google Base!

The fix is to tell the GClient API to use the Google account only, not the HOSTED_OR_GOOGLE default. I found others have suggested this fix (or the workaround of using a non-Google Apps account) here.

The gist of it is to change this function call by adding two extra parameters: app\code\core\Mage\GoogleBase\Model\Service.php on line 49. The two parameters to add are: Zend_Gdata_ClientLogin::CLIENTLOGIN_URI, 'GOOGLE' as shown below.

$client = Zend_Gdata_ClientLogin::getHttpClient($user, $pass, Zend_Gdata_Gbase::AUTH_SERVICE_NAME, null, '', $loginToken, $loginCaptcha, Zend_Gdata_ClientLogin::CLIENTLOGIN_URI, 'GOOGLE');

That fixed the problem for me, now I just have to figure out which of the required Google Base attributes I’m missing!

A while ago a slipped a bonus point question/jibe into one of my reviews for Magento hosting. Justin has cleverly called me on it, so as promised, you should check out Fat Cows eco friendly web hosting.

Oddly enough their hosting does actually look interesting, the idea of wind powered green hosting, isn’t one I’d heard of before.

What happens on non-windy days though? (I’m guessing they don’t rely soley on wind!) But they could make that clearer on the site.

Anyway, cool idea, if you want hosting for a Magento webstore with a green/eco point of difference then it’s probably a good option. You can then brag about it on your site, give you customers a warm fuzzy feeling! Go Get It!

I normally always want to remove the Compare/Add to Compare functionality from the Magento stores I create, and in the past have changed the template files as though the compare functionality is being hidden in the theme. In a lot of ways that’s probably a fairly reasonable way to disable it, but something seems clunky about going through a bunch of phtml files in Magento directories grep‘ing and replacing Add to Compare everywhere. I recently did it a different way, that although may be slightly less well separated from the core Magento functionality (in terms of keeping the changes at the UI layer) – I think it makes it clearer.

There are really only two three four (Thanks Matt and Paulo) steps to removing the compare functionality, and they’re all fairly easy, here’s how to do it:

Disable comparison functionality in Magento

I did this on the command line, but I’ll explain the commands for those of you stuck in cPanel/Plesk/GUI hell. These commands are all run from the root of your Magento store.

First create the local override directory:

mkdir -p app/code/local/Mage/Catalog/Helper/Product/

Making this local code directory that mirrors the core Mage folder structure will allow Magento to pick up your custom file. WHich we now make by copying the original from app/code/core/Mage/Catalog/Helper/Product/Compare.php and putting it in the new directory we made app/code/local/Mage/Catalog/Helper/Product/:

cp app/code/core/Mage/Catalog/Helper/Product/Compare.php app/code/local/Mage/Catalog/Helper/Product/

Now we just make one small change to the file, by basically telling this helper to never return a comparison URL, the front end will never show the add to compare links. The change is made in the getAddUrl() function.

 public function getAddUrl($product)
    {
        #return $this->_getUrl('catalog/product_compare/add', $this->_getUrlParams($product));
        # We disable compare functionality by commenting out the real return statement and returning false instead.
        # Returning a boolean from a function that should return a string, somewhere, a kitten dies.
        return false;
    }

Save the file and you’re done. Now when you refresh the product/category page (you disabled the Magento cache right?) then you’ll no longer see the ‘add to compare’ links by the add to cart buttons.

Remove the Compare sidebar element

There is also the matter of the sidebar element, here’s the easy way to get rid of that.

Edit your theme’s catalog.xml file which is found in the app/design/frontend/X/Y/layout/ directory, where X and Y are your theme and package, possibly just default and default.

Remove the part that looks like this within the first <default> element:

 <reference name="right">
            <block type="core/template" before="cart_sidebar" name="catalog.compare.sidebar" template="catalog/product/compare/sidebar.phtml"/>
            <block type="core/template" name="right.permanent.callout" template="callouts/right_col.phtml"/>
 </reference>

This has the nice side effect of removing the back to school specials block too, obviously if you are actually running a back to school special, then only remove this line from the <reference> element:

<block type="core/template" before="cart_sidebar" name="catalog.compare.sidebar" template="catalog/product/compare/sidebar.phtml"/>

Edit: Thanks to Matt for pointing this out.

To remove the compare sidebar from the My Account section of the Magento store edit the file: customer.xml inapp/design/frontend/X/Y/layout/. Find the section:

<customer_account>

And remove this line from it:

<block type="core/template" name="catalog.compare.sidebar" template="catalog/product/compare/sidebar.phtml"/>

Edit: And thanks to Paulo for pointing this out – the compare sidebar is also included in the reports.xml file, so remove it from there in the same way:

<default>
    <!-- Mage_Reports -->
    <reference name="right">
        <block type="reports/product_viewed" before="right.permanent.callout" name="right.reports.product.viewed" template="reports/product_viewed.phtml" />
        <block type="reports/product_compared" before="right.permanent.callout" name="right.reports.product.compared" template="reports/product_compared.phtml" />
    </reference>
</default>

The line to remove is:

<block type=”reports/product_compared” before=”right.permanent.callout” name=”right.reports.product.compared” template=”reports/product_compared.phtml” />

And that should be it, no more compare functionality. Maybe it’d be nice to make this into a Magento extension, so that it can be enabled and disabled on the admin interface. If there is enough interest in that, I’ll bundle up my code change, it’s really only one file, after all. If you’re after something like that – let me know.

Wow, long time, no post – no excuses really*, just been really busy. This post will give you a quick tip for masking password fields in your Magento extensions. I wanted to mask the password in my Google Apps and Gmail Magento Extension and despite a few Google searches, I couldn’t find a simple answer. There’s also not really any good documentation on the various configuration xml files in Magento, it seems.

Thankfully i960 over at the Magento forums gave me this simple tip, which I think should be shared. Here’s how to mask or hide your admin passwords in the backend of Magento. This is particularly useful when creating your own Magento extensions.

In etc/system.xml add xml like this:

 <password translate="label">
    <label>Password</label>
    <frontend_type>password</frontend_type>
    <sort_order>10</sort_order>
    <show_in_default>1</show_in_default>
    <show_in_website>1</show_in_website>
    <show_in_store>0</show_in_store>
</password>

The key being the frontend_type of password in case you hadn’t noticed that.

Anyway expect me to be a bit more active with some Magento tips over the next few weeks.

*In a lot of ways you can blame Amazon for creating some of the worst financial reports I have ever had to work with! Parsing those to pull meaningful information has been like pulling teeth. Anyway I’ll add some feedback on those in an upcomming post.