ServerBear Web Performance Blog

This text is controlled by the user, they can use it to articulate to their followers how to enter, or whatever they want :) Oh, they can also use HTML if they want.

Test Gleam Competitions

Test <a href="https://blah.com">Blah</a>

TEst

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 number of other websites 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.

Traffic Stats

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.

In total we've had 5,561 visits since launch, which has resulted in over 4,500+ visits to web hosts (which is an incredible click through rate, we do suspect that search engine bots might be inflating our internal numbers).

You'll see that we're getting close to no search engine traffic yet, we probably don't have enough links for the Google gods to trust us. Konstantin from VPSeer kindly linked to us from his VPS SSD Performance Chart last week (Thanks!), as with all good products we hope that these types of links will just happen naturally over time.

Low End Talk: I stumbled across this awesome community whilst doing some research, there's a lot of smart people here who run their own hosting companies (a few I've spoken with: Tim from Hostigation, Nick from RAMNode, Elliot from Virt.io, Kevin from URPad, Simon from MiniVPS, Corey from Front Range Hosting, Jacob from EaseVPS, Joe from Secure Dragon & Jack from DotVPS) - they have provided great support & have almost adopted us as their standard test when launching new offers or plans. We really need to continue to provide value to communities, especially those that care about the performance of their servers.

Web Hosting Talk: This forum is where the industry hangs out, it's been a great way to network with web hosts & answer questions. Again we've been trying to provide value in every post here, but WHT (as it's known for short) is similar to Digital Point in that there's a lot of uneducated people that just reduce the quality of this forum to mush. You'll see more posts about people complaining about downtime, or too many pointless filler posts from hosts trying to inflate their post count.

Hacker News: One of John's good friends posted the site to Hacker News, and whilst we got only about 8 up-votes I was quite surprised about the amount of traffic it sent us. I think we could have done more justice with the title of the post, but alas we weren't in control of posting it. We also didn't get much feedback from this particular set of users, so we probably need a different angle like (showing the web hosting choices of the latest YC batch).

Twitter: We've been getting into Twitter a lot lately, it's been useful to announce when we add a new host & benchmarks. We're getting good traction from hosts also retweeting us to their followers when we give them some nice data. Here's a good example of Joyent retweeting us after we benchmarked their plans (to over 9k followers). Don't forget to follow us if you use Twitter :)

Site Stats

We've been working pretty hard, mostly in the evenings & weekends to improve our stats. For me the single most important metric is new benchmarks, the more coverage we have the more & more valuable our dataset becomes - which in turn to should to authority within the industry (or so we hope):

456 New Benchmarks

An 85% success rate contacting web hosts & asking to provide benchmarks (or an account for us to run benchmarks). To me this really validates that we're providing some sort of value.

62 Hosts have contacted us directly via our contact form

143 New Hosts Added (2.38 per day)

1089 Hosting Plans Added (18 per day)

13% of the links to hosts are currently affiliated (i.e have the chance to earn us revenue)

80k+ Lines of Plan Data (This includes RAM/HDD Size/CPU Cores, all the data that will make it easier for you to filter by a specific need)

71 Hosting Coupons (quite a bit less than we'd like, we're planning to improve this part of the site)

79 Tweets & 43 Twitter followers (we only started this on 8th Aug)

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.

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

IOPS

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

Then a seek rate test.

ioping -R /dev/xvdf --- /dev/xvdf (device 1024.0 Gb) ioping statistics --- 12296 requests completed in 3000.2 ms, 7817 iops, 30.5 mb/s min/avg/max/mdev = 0.1/0.1/0.4/0.1 ms

Now we'll test the sequential writes

--- . (ext3 /dev/xvdf) ioping statistics --- 3377 requests completed in 3000.4 ms, 1344 iops, 336.0 mb/s min/avg/max/mdev = 0.6/0.7/2.6/0.2 ms

DD

dd if=/dev/zero of=test bs=1M count=1k oflag=dsync 1073741824 bytes (1.1 GB) copied, 3.75235 s, 286 MB/s

dd if=/dev/zero of=test bs=64k count=16k oflag=dsync 1073741824 bytes (1.1 GB) copied, 13.4007 s, 80.1 MB/s

dd if=/dev/zero of=test bs=1M count=1k conv=fdatasync 1073741824 bytes (1.1 GB) copied, 3.25754 s, 330 MB/s

dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync 1073741824 bytes (1.1 GB) copied, 3.3367 s, 322 MB/s

There seems to be an issue with disk performance in dsync mode, we see this often with SSD drives. We we really need to use a bigger file to test the sustained performance.

dd if=/dev/xvdf of=test bs=1M 7646380032 bytes (7.6 GB) copied, 17.4732 s, 438 MB/s

hdparm -tT /dev/xvdf /dev/xvdf: Timing cached reads: 14502 MB in 1.99 seconds = 7289.54 MB/sec Timing buffered disk reads: 1142 MB in 3.00 seconds = 380.53 MB/sec

UnixBench

------------------------------------------------------------------------ Benchmark Run: Fri Jul 20 2012 02:40:24 - 03:08:35 16 CPUs in system; running 1 parallel copy of tests Dhrystone 2 using register variables 24160326.4 lps (10.0 s, 7 samples) Double-Precision Whetstone 2989.9 MWIPS (10.0 s, 7 samples) Execl Throughput 986.9 lps (30.0 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 271531.6 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 70013.0 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 802038.9 KBps (30.0 s, 2 samples) Pipe Throughput 410363.6 lps (10.0 s, 7 samples) Pipe-based Context Switching 44733.0 lps (10.0 s, 7 samples) Process Creation 2211.5 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 3919.1 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 1538.9 lpm (60.0 s, 2 samples) System Call Overhead 441575.6 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 24160326.4 2070.3 Double-Precision Whetstone 55.0 2989.9 543.6 Execl Throughput 43.0 986.9 229.5 File Copy 1024 bufsize 2000 maxblocks 3960.0 271531.6 685.7 File Copy 256 bufsize 500 maxblocks 1655.0 70013.0 423.0 File Copy 4096 bufsize 8000 maxblocks 5800.0 802038.9 1382.8 Pipe Throughput 12440.0 410363.6 329.9 Pipe-based Context Switching 4000.0 44733.0 111.8 Process Creation 126.0 2211.5 175.5 Shell Scripts (1 concurrent) 42.4 3919.1 924.3 Shell Scripts (8 concurrent) 6.0 1538.9 2564.9 System Call Overhead 15000.0 441575.6 294.4 ======== System Benchmarks Index Score 527.9 ------------------------------------------------------------------------ Benchmark Run: Fri Jul 20 2012 03:08:35 - 03:36:59 16 CPUs in system; running 16 parallel copies of tests Dhrystone 2 using register variables 201313595.2 lps (10.0 s, 7 samples) Double-Precision Whetstone 40724.6 MWIPS (10.1 s, 7 samples) Execl Throughput 8050.6 lps (29.9 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 348105.5 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 95790.4 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 1189159.8 KBps (30.0 s, 2 samples) Pipe Throughput 4705588.4 lps (10.0 s, 7 samples) Pipe-based Context Switching 634652.9 lps (10.0 s, 7 samples) Process Creation 14990.6 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 21494.0 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 2880.1 lpm (60.2 s, 2 samples) System Call Overhead 4191761.5 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 201313595.2 17250.5 Double-Precision Whetstone 55.0 40724.6 7404.5 Execl Throughput 43.0 8050.6 1872.2 File Copy 1024 bufsize 2000 maxblocks 3960.0 348105.5 879.1 File Copy 256 bufsize 500 maxblocks 1655.0 95790.4 578.8 File Copy 4096 bufsize 8000 maxblocks 5800.0 1189159.8 2050.3 Pipe Throughput 12440.0 4705588.4 3782.6 Pipe-based Context Switching 4000.0 634652.9 1586.6 Process Creation 126.0 14990.6 1189.7 Shell Scripts (1 concurrent) 42.4 21494.0 5069.3 Shell Scripts (8 concurrent) 6.0 2880.1 4800.1 System Call Overhead 15000.0 4191761.5 2794.5 ======== System Benchmarks Index Score 2652.2

The server seems to struggle in UnixBench with the low buffer size file copy tests, but excels in the Shell Script tests. The CPU is a Intel Xeon E5620 which is disappointing, it seems like it could be really holding this particular instance back when you consider some of the higher end CPU's (E5 Series) benchmark up to 400x better.

Price

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:

Dhrystone

Whetstone

Execl Throughput

File Copy

Pipe Throughput

Pipe-based Context Switching

Process Creation

Shell Scripts

System Call Overhead

Graphical Tests

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:

wget http://byte-unixbench.googlecode.com/files/UnixBench5.1.3.tgz tar xvf UnixBench5.1.3.tar.gz cd UnixBench5.1.3 ./Run

Use ServerBear

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.

If you're in the market for any type of shared hosting plan you'll probably see the word unlimited used heavily. But let's take a step back for a moment & understand more about if it's really possible to offer true unlimited hosting.

In What Context Is Unlimited Used?

Let's use Dreamhost as an example, they only have one shared hosting plans which offers the following goodies:

Unlimited Storage

Unlimited Bandwidth

Unlimited Domains

Unlimited Shell Users

Unlimited Email Accounts

Unlimited MYSQL Databases

Unlimited Domains

Unlimited Subdomains

Well know that there's no such thing as an unlimited TB hard drive, or an unlimited amount of bandwidth - these are finite resources (the host must have some sort of hard limit somewhere). Everything else however can technically be unlimited (until the point at which you exhaust your server or finite resources).

All Unlimited Plans Are Not Equal

This is where things get interesting, many hosts will advertise unlimited Storage or Bandwidth but will have reasonable limits stated within their TOS. Users may not be aware of the actual resource usage limits placed on their account (namely CPU & RAM), these two resources have the biggest potential to impact other users on the shared hosting node you reside on.

Here’s HostGators TOS:

Use 25% or more of system resources for longer then 90 seconds. There are numerous activities that could cause such problems; these include: CGI scripts, FTP, PHP, HTTP, etc.

Run stand-alone, unattended server-side processes at any point in time on the server. This includes any and all daemons, such as IRCD.

Run any type of web spider or indexer (including Google Cash / AdSpy) on shared servers.

Run any software that interfaces with an IRC (Internet Relay Chat) network.

Run any bit torrent application, tracker, or client. You may link to legal torrents off-site, but may not host or store them on our shared servers.

Participate in any file-sharing/peer-to-peer activities

Run any gaming servers such as counter-strike, half-life, battlefield1942, etc

Run cron entries with intervals of less than 15 minutes.

Run any MySQL queries longer than 15 seconds. MySQL tables should be indexed appropriately.

When using PHP include functions for including a local file, include the local file rather than the URL. Instead of include(“http://yourdomain.com/include.php”) use include(“include.php”)

To help reduce usage, do not force html to handle server-side code (like php and shtml).

Only use https protocol when necessary; encrypting and decrypting communications is noticeably more CPU-intensive than unencrypted communications.

The restrictions here are quite specific, if you’re running a Wordpress blog & get a massive burst of traffic it’s very likely that you could get your account suspended for utilising too much resources on your node.

The Math Behind Unlimited Bandwidth

There’s plenty of hosts that offer unlimited bandwidth or unmetered bandwidth. The amount of bandwidth that your server can use is limited to the uplink that your hosting provider has to their carriers.

Generally you will find hosts that have the following port speeds (in Megabits or Gigabits per second):

10Mbps: 3.2 Terabytes / month

100Mbps: 32.4 Terabytes  / month

1Gbps: 324 Terabytes / month

10Gbps: 3.2 Petabytes  / month

100Gbps: 32.4 Petabytes  / month

So the limit of the port speed on your server alone will place restrictions on your plan, therefore your bandwidth technically isn’t unlimited (as there is a true point at which your will saturate your connection).

Customer Expectations

We see time & time again that customers fail to understand the true meaning of unlimited. Instead they get drawn in by the allure of unlimited resources at a very low cost.

This in itself creates a number of problems for web hosts:

Your users expect the world from your hosting packages if you do not set realistic resource limits.

This results in complaints & negative reviews online.

This in turn creates another problem, web hosts that offer unlimited plans tend to lock customers in by only allowing them to pay for 1 or more years in advance. Bluehost is a prime example of this. And here's an excerpt from their TOS:

Bluehost does not set arbitrary limits on the amount of disk space a Subscriber can use for the Subscriber's website, nor does Bluehost charge additional fees based on an increased amount of storage used, provided the Subscriber's use of storage complies with these Terms. Please note, however, that the Bluehost service is designed to host websites. Bluehost does NOT provide unlimited space for online storage, backups, or archiving of electronic files, documents, log files, etc., and any such prohibited use of the Services will result in the termination of Subscriber's account, with or without notice. Accounts with a large number of files (inode count in excess of 200,000) can have an adverse affect on server performance. Similarly, accounts with an excessive number of MySQL/PostgreSQL tables (i.e., in excess of 1000 database tables) or of database size (i.e., in excess of 3GB total MySQL/PostgreSQL usage or 2GB MySQL/PostgreSQL usage in a single database) negatively affect the performance of the server. Bluehost may request that the number of files/inodes, database tables, or total database usage be reduced to ensure proper performance or may terminate the Subscriber's account, with or without notice.

So you have to be extremely careful when signing up for 12 or more months as if you use to many resources you could find yourself with a terminated account & no refund.

Still Thinking About An Unlimited Plan?

If you are still considering an unlimited plan then make sure you do your homework, the following tips should help you make a better choice:

Avoid hosts that make you pay upfront for a year or more at a time.

Don't be fooled by the lure of unlimited. Often you'll get better value/performance with hosts that have properly defined limits.

Be careful with "reviews" there are a lot of affiliate only review websites designed purely to make money around popular web hosts.

Always read the TOS to see what the fair use policy is at the host.

Test multiple hosts, you may have to invest a small amount of money to find a host that suites your needs.

Don't expect the world from a shared hosting environment, after all you are sharing a server with potentially hundreds of other people.