In the last month we’ve really been trying to push our coverage of benchmarks for cloud hosting, since Atlantic.Net offers a free trial it was easy for us to get good benchmark coverage across all of their plans. They currently outperform the majority of other providers in our Cloud IO Benchmarks so we were intrigued to learn more.
Marty Puranik, the CEO & Founder of Atlantic.Net took some time out of his busy schedule to ask a few questions & get into a bit of detail about their cloud offering.
Atlantic.Net has been around for a long time in Internet terms (since 1994). Tell us a little bit about the company.
Atlantic.Net was founded in 1994 and started off providing Internet access. We’ve obviously changed and re-invented our business model several times, morphing into a high-speed DSL provider, Colocation provider, and now a Cloud hosting provider. We’re passionate about technology and trying to do big things.
What’s the culture like at Atlantic.Net?
Atlantic.Net is a company focused on trying to do the best we can. Our hope is that even if it’s for a split second, we’ve pushed humanity forward in some way or done something no one has done before. Every day we try to improve what we do, even if it’s an incremental change. We also try to use reason and logic to make our decisions, and in that sense we are pragmatic. Overall, I would say we’re reaching for stars, trying to pioneer new ideas. We’re basically looking for the romance and fairy-tale of building an amazing business.
WordPress has fast become the goto open source Blogging/CMS platform on the web. It brings simplicity & functionality to the end user, but still needs a fair amount of tweaking to perform fast. Chances are if you’re reading this guide then you’re semi-interested in finding out how you can improve the performance of your WordPress install.
In this guide we’re going to take you step by step through setting up a brand new server with a WordPress install from scratch, this includes all the server optimization & WordPress plugins. We’ve split the guide up into parts that you can see in the tabs below.
We are not recommending WordPress hosts in this post, however we are giving you the smarts you need to make a calculated decision on your own. Be wary of websites that flat out recommend hosts (most likely they are getting paid for it).
In this guide everything we do will be on the Linux command line, if you’re used to control panels (like CPanel or DirectAdmin) then this may seem a little daunting at first. But trust me, ditching the control panel will do wonders for your performance & also your general knowledge of the Linux operating system.
We’ve been working closely with a number of hosts in the last few months & we decided it’d be great to understand a little more about their business – including there thoughts on the industry & hopefully get into some of the technical detail about their setups. Use our contact form to get in touch if you’d like to participate.
Nick Adams (@Mr_Nicky_A) the owner of RamNode has kindly taken the time to answer some questions I sent him, I’ve tried to tailor the questions to each host to hopefully mix things up & bit plus touch on some different topics.
RamNode isn’t your first web hosting company. Tell us a little bit about how you got started?
I started back in 2006 doing shared web hosting at NickHost.net. It was a natural transition from designing small websites for a family friend to hosting those websites and eventually others for local contacts. Then after a few years of basically running NickHost as a hobby, I started promoting my services on Twitter. I eventually gained larger clients with needs for more robust hosting solutions than what I currently offered. At that point I jumped into the VPS hosting market, just trying to offer enough RAM to serve a few of those bigger clients. Around the same time, Minecraft hosting caught my eye. It was really starting to take off and I fortunately had the resources available to enter the market with a quality product. I originally hosted a few Minecraft servers at NickHost before founding MinecraftLayer around August of 2011. I never had any interest in really targeting the general VPS market until a friend suggested it in May of this year. That’s when I started RamNode, and we haven’t looked back since!
The last month has flown past in a blur of fur & benchmarks, as promised we’re planning to keep these monthly posts going so you can get an idea of how ServerBear is progressing, whether or not we’re growing & what new features we’re actively working on.
Last month I was on holidays in the beautiful town of Byron Bay for over a week, which meant I had some much needed downtime to speak with hosts & get lots of content added. This month, the tables turned on us & we found ourselves not needing to be as proactive but getting a lot more requests from hosts & users organically. This in itself is great but also problematic, I’ve found myself spending less time on reaching out to hosts for benchmarks. Something I plan to correct in October.
Some good growth this month with a total of 9,443 visits, that’s almost a 100% increase over the previous 2 months combined. You’ll notice a few jumps in the traffic levels on the chart below, these can be attributed to a few things:
Our update post got quite a bit of traction on Low End Talk last month.
At ServerBear we help web hosts connect better with customers by providing a more transparent insight into their performance & plans. We’re trying to make public data that’s generally hidden under the surface, data that you don’t normally get to see until after you sign up.
This got me thinking about the reasons why people might choose a certain provider, let’s separate these reasons into Public & Private.
These are reasons that the user can predetermine themselves, through research without having to actually signup.
Lets pretend for the purpose of this post there’s three very different types of hosts:
You then have up & coming companies that have previously spent more of their energy on providing a good service & infrastructure but relied on word of mouth to grow (think Linode or Singlehop), you’ll see a lot of these companies climb the ranks in the INC 500.
Finally you have the smaller companies, they could be one man shows (i.e. Hostigation) or have a handful of employees (like 6sync). Some will own their own hardware, others will lease their hardware from suppliers like OVH or Hetzner.
At the moment ServerBear is a website, we’re hoping that eventually we can build it into a business. It’s something that both myself (@thegyppo) & my co-founder John (@ponny) are passionate about, we also think there’s a huge gap in the marketplace for what we’re doing.
We’ve both made a conscious decision that the best way to run our site is through openness & transparency, which is why we’ve decided to reveal our data every month here on the blog, so you can see what we’re doing, how we’re performing & whether or not we’re failing or succeeding (hopefully not the former!).
For the record, ServerBear is not our fulltime gig. We both work full time jobs & our startup (Crowd9) has a numberofotherwebsites that we maintain. These generate income for us, but we don’t have the same opportunity to make an impact like we do with ServerBear.
With ServerBear we have to try & get the point where we reach a critical mass. We want to be the goto place that people trust to find accurate data about web hosting. This is not an easy task, but we are approaching this from a different perspective. We feel that we need to build something that is primarily useful for web hosts, we want you to want to work with us & we will do whatever it takes to add as much value as we can, we have the power to make people think twice about your company if you provide a better level of performance & quality than a big name hosting company (and we’ll mention a few of these host that we’ve worked with this month).
We also have to make a living, the world is becoming more expensive, both John & I both have familes, kids & mortgages. We need to make a serious impact if we’re ever to both consider working on ServerBear full time.
We launched officially on 24th July 2012, the site itself has been live from 22nd June 2012 but we’ve been iterating based on feedback.
I’ve been noticing a worrying trend lately that whenever a web host goes down, due to network issues or hardware issues their website tends to go down with it.
In many safety-critical systems, such as fly-by-wire and hydraulic systems in aircraft, some parts of the control system may be triplicated. An error in one component may then be out-voted by the other two. In a triply redundant system, the system has three sub components, all three of which must fail before the system fails.
This only adds fuel to the fire, if your website or blog is down you have no way to communicate issues to your clients & the longer you take the more agitated they will get.
As a web host you should always consider hosting your main site outside of your network. I know it might feel shameful, but by spreading yourself across multiple networks you reduce the probability that multiple systems will be down simultaneously.
You can always use subdomains to your advantage too, if you have a status.hostname.com to deliver network status updates to customers then it’s easy to ensure this is on another network with failover (this particular subdomain is critical to keeping customers in the loop).
If All Else Fails?
If all else fails then you have a few final options to keep your customers informed:
Use a service like Mailgun for your email. You can send an email to customers informing them of any outages.
Be active in social networks like Twitter & Facebook, encourage users to follow you for network updates.
Use forums to let your customers & peers know that you are experiencing issues.
If you stay silent customers will automatically assume the worst – that you’ve gone out of business. You could lose customers who panic, forum posts will crop up & you’ll do more harm; all because you decided against hosting your assets with competitors.
Amazon announced today the release of a new EC2 instance type targeted at high I/O dependant applications. We’ve run benchmarks on a lot of the Amazon plans in the past & found them to be rather lacklustre in terms of performance.
High I/O Quadruple Extra Large Instance Specs (hi1.4xlarge)
60.5 GB of memory
35 EC2 Compute Units (8 virtual cores with 4.4 EC2 Compute Units each)
CPUs: Intel Xeon E5620
2 SSD-based volumes each with 1024 GB of instance storage
Uplink: 10 Gigabit Ethernet
Firstly lets run with Cached IO. From previous SSD testing we should expect this upwards of the 800mb/s mark.
ioping . -c 10 -C
4096 bytes from . (ext3 /dev/xvdf): request=1 time=0.0 ms
4096 bytes from . (ext3 /dev/xvdf): request=2 time=0.0 ms
4096 bytes from . (ext3 /dev/xvdf): request=3 time=0.0 ms
4096 bytes from . (ext3 /dev/xvdf): request=4 time=0.0 ms
4096 bytes from . (ext3 /dev/xvdf): request=5 time=0.0 ms
4096 bytes from . (ext3 /dev/xvdf): request=6 time=0.0 ms
4096 bytes from . (ext3 /dev/xvdf): request=7 time=0.0 ms
4096 bytes from . (ext3 /dev/xvdf): request=8 time=0.0 ms
4096 bytes from . (ext3 /dev/xvdf): request=9 time=0.0 ms
4096 bytes from . (ext3 /dev/xvdf): request=10 time=0.0 ms
--- . (ext3 /dev/xvdf) ioping statistics ---
10 requests completed in 9000.9 ms, 217391 iops, 849.2 mb/s
min/avg/max/mdev = 0.0/0.0/0.0/0.0 ms
Then Direct IO. This number is actually comparable to some of the RAMNode SSD plans.
ioping . -c 10 -D
4096 bytes from . (ext3 /dev/xvdf): request=1 time=0.2 ms
4096 bytes from . (ext3 /dev/xvdf): request=2 time=0.3 ms
4096 bytes from . (ext3 /dev/xvdf): request=3 time=0.3 ms
4096 bytes from . (ext3 /dev/xvdf): request=4 time=0.3 ms
4096 bytes from . (ext3 /dev/xvdf): request=5 time=0.3 ms
4096 bytes from . (ext3 /dev/xvdf): request=6 time=0.3 ms
4096 bytes from . (ext3 /dev/xvdf): request=7 time=0.3 ms
4096 bytes from . (ext3 /dev/xvdf): request=8 time=0.3 ms
4096 bytes from . (ext3 /dev/xvdf): request=9 time=0.3 ms
4096 bytes from . (ext3 /dev/xvdf): request=10 time=0.3 ms
--- . (ext3 /dev/xvdf) ioping statistics ---
10 requests completed in 9003.5 ms, 3700 iops, 14.5 mb/s
min/avg/max/mdev = 0.2/0.3/0.3/0.0 ms
UnixBench is part of core benchmarking methodology here at ServerBear, it provides a performance overview at a system level by testing a number of various factors:
Pipe-based Context Switching
System Call Overhead
At the end you’ll get an overall system score for a single process utilising 1 CPU Core or parallel processes utlising all the CPU Cores in your system. If you want an idea on how your server compares to other hosts you can check our server benchmarks.
There’s two ways you can get UnixBench running on your Ubuntu system:
Compile It Yourself
In order to compile Unixbench yourself you will need to make sure you have the right packages installed in Ubuntu:
apt-get install libx11-dev libgl1-mesa-dev libxext-dev perl perl-modules make
Once everything is installed you can then grab the latest UnixBench version (5.1.3) from Google Code, the following command will also run UnixBench:
The above method is fine if you just want your UnixBench score, however if you also want a deeper understanding of IO Peformance, IOPS plus a way to compare your UnixBench score with other servers & plans then we make it super easy for you. Here’s an example of one of our reports.
ServerBear makes it easy to benchmark Linux servers & compare performance metrics (Disk IO, IOPS, FIO, Network Performance & UnixBench).
Don't settle for poor server performance from your current host, run a benchmark & instantly compare results against over 1000+ plans: