Snipe.Net Geeky, sweary things.

And Still More Notes on Mosso


Continuing in the Moving to Mosso series, I’ve come across a few more issues that anyone considering moving to Mosso should consider.

I’ve been with them for over two months now, and am very happy with them. Like the previous article, these issues are not dealbreakers – at least they are not to me – but they’re things I didn’t know about until I had made the switch, so it may be helpful for you to know in advance.

No access to memcached or APC caching modules

While this wouldn’t normally be much of an issue in many cases, if you have a very high traffic website, you may want to consider caching your dynamic pages so that you don’t exceed your allotted cpu cycles. From what I hear, Mosso is working on supporting APC and setting up a memcached server, but as of right now, it is not available.

There are, of course, other caching options such as PEAR’s Cache_Light and Zend Cache, or the “quick and dirty” method – but when you’re using query-heavy third-party software such as vBulletin, where implementing a scripted cache involves a significant amount of work, it’s a bit of a drag.

No editing a domain after you create it

Unlike other control panels, you cannot edit a domain name once you’ve created it. If you decide to change your domain name, you’ll either have to handle redirection through mod_rewrites to mask urls, or create a new domain account and then download+upload the content and databases. Hopefully you won’t have to do this often, but I admit I was surprised to discover that not even the tech support guys could facilitate editing a domain name once the account was created. Bit of a pain in the ass, but hopefully it won’t come up again.

Node/cookie weirdness

This one threw me for a loop, but now that I know about it, it’s an easy thing to work around. The way the load balancer works, a cookie is set when you access a page on the server, that tells the load balancer which node you came from, so that your sessions can be preserved. The only hitch is that if by some fluke you hit a server node error (meaning the load balancer couldn’t find a suitable node within 60 seconds), that cookie can keep sending you back to the node that isn’t answering/doesn’t exist anymore. This sounds rather complicated, but it’s actually not:

If you hit a server node error, and continue to see the server node error although people on other computers can see your site just fine, try clearing your cookies. I know, I know – it sounds like bullshit – but when you clear your cookies, the load balancer will stop trying to send you to a non-existent node and will find a suitable working node for you.

I’ve only had this come up once, but it was frustrating an confusing until we got it figured out. And as always, many thanks to Robert Collazo in their tech dept for his eternal patience and amazing dedication to getting to the bottom of things.

CPU-based billing

As you may already know, Mosso uses CPU cycles as part of their billing determination. You are allotted 10k CPU cycles, and are charged one penny per cycle if you go over.  For most people, this will not be a big deal at all, however because most servers don’t report on your CPU usage, it can be challenging to figure out how many CPU cycles you’re using until you’ve made the switch. The vast majority of Mosso customers don’t even come close to exceeding their allotted CPU cycles. I happen to be an exception, largely because one of my sites gets over a half a million media-and-databasae-heavy pageviews a month, and I have 100 other sites ranging from very large to very small on the box.

What this ultimately means to you is that it is absolutely in your best interests to make sure your scripts and sites are running at peak efficiency. Double-check your database indexes, implement page caching where applicable, turn off gzip compression, etc. While you likely won’t find yourself needing to hoard your cpu cycles, knowing that the steps you take towards efficiency could impact your wallet is a compelling reason to take a hard look at your sites and figure out where you can do some fine-tuning, which is, overall, not such a bad thing.

Thoughts so far

I’ve really been quite satisfied with the speed, uptime, and absolutely the support provided by Mosso since I signed on in January. Nothing I’ve come up against has been dealbreaker material, and the few issues I’ve had have been resolved quickly and professionally by their support staff.

Although it may seem like much of my review is nitpicking on what you can’t do on Mosso, that’s only because the rest of it just *works*, so there’s not much more to say about it. I could go through the list of what just *works* to balance out the arguably-bad with the good, but that would be stupid. Great uptime, great support, great price. Happy customer.

Ready to give Mosso a try?

If you’re interested in giving Mosso a shot, they offer a 30 day risk-free trial (money back guarantee) – and if you use the promotional code REF-SNIPE, you’ll get a $25 rebate/refund on your first month’s bill. If you’re still not sure or you have more questions, follow @mosso on twitter. They’re very responsive, and often quite funny.

About the author


I’m a tech geek/dev/infosec-nerd/scuba diver/blacksmith/sword-fighter/crime fighter/ENTP/warcrafter/activist. I run Grokability, Inc, and run several open source projects, including Snipe-IT Asset Management. Tweet at me @snipeyhead or read more...

By snipe
Snipe.Net Geeky, sweary things.

About Me

I’m a tech geek/dev/infosec-nerd/scuba diver/blacksmith/sword-fighter/crime fighter/ENTP/warcrafter/activist. I run Grokability, Inc, and run several open source projects, including Snipe-IT Asset Management. Tweet at me @snipeyhead or read more...

Get in Touch