Checking Out Linode

I recently posted a sort of comparison between DreamCompute’s and DigitalOcean’s cloud compute services. I was curious about the performance of their virtual servers, in terms of CPU and storage I/O. Someone people have suggested I check out Linode too. It wasn’t on my radar, but I suppose I have to check them out too for my own hosting considerations.

Linode has been around for a long time. They were originally using Xen virtualisation, which is more of a OS-level virtualisation rather than a whole hardware virtualisation. But they’ve since switched to hardware level virtualisation using KVM, the same technology used by DreamCompute and DigitalOcean. Linode also boasts SSD servers, and price tiers that somewhat match DigitalOcean’s, but aren’t really completely comparable. I’ll leave the pricing comparisons for you to do on your own.

My main interests is with performance comparisons. So let’s look at Linode’s figures, in comparison with DreamCompute and DigitalOcean. Here’s a quick description of the test servers:

• US-East-2: This is DreamCompute’s new SSD cluster located at their US-East-2 data centre. Virtual servers are sized with 1 GB RAM and 80 GB of ephemeral storage. Ephemeral storage is OpenStack’s equivalent of AWS’ instance storage.
• DO-SGP: This is a virtual server at DigitalOcean’s Singapore data centre. It’s also sized with 1 GB of RAM, and has 30 GB of instance storage.
• LI-NW-1: This is a virtual server at Linode’s Newark data centre. It is sized with 1 GB of RAM. Unfortunately, the included 24 GB disk storage is insufficient for Bonnie++ tests I’ve run at US-East-2 and DO-SGP. I had used 24 GB file sizes, and since there’s not enough free disk space left, I run Bonnie++ with 20 GB size here.
• LI-NW-2: To get 24 GB size test, I’ve provisioned a second Linode server at the same Newark data centre. This has 2 GB of RAM, and has 2 CPU, and 48 GB of disk. Note that all the other virtual servers above only have 1 GB of RAM and 1 CPU.

So here are the CPU speed tests using sysbench and OpenSSL. The OpenSSL speed test is on 4096-bit RSA operations, run with openssl speed rsa4096, and the numbers in the table below are for the sign and verity operations per second.

	US-East-2	DO-SGP	LI-NW-1	LI-NW-2
sysbench-cpu	33.5	36.4	32.4	32.4
openssl-rsa4096	110.0/6972.8	96.8/6541.9	94.2/5908.1	92.4/5894.9

Here are the Sysbench fileio test numbers.

	US-East-2	DO-SGP	LI-NW-1	LI-NW-2
Time to prepare (sec)	154	229	26	26
Throughput (MB/s)	3.1458	22.853	112.75	115.51
Requests/sec	201.33	1462.58	7216.2	7392.5
Average request time	1.01	0.18	0.09	0.08
95-percentile request time	2.47	0.63	0.16	0.17

Then, here are the Bonnie++ results. Remember it’s 24 GB files, except for LI-NW-1 that I ran with 20 GB because of the small disk space.

	US-East-2	DO-SGP	LI-NW-1	LI-NW-2
Sequential Output	213409	81117	993403	962571
Sequential Rewrite	23770	79907	529560	562975
Sequential Input	114943	299580	908360	935594
Random Seeks	3998	++++	14215	++++

It looks like Linode servers are pretty good. In particular, their storage is really fast, in every way. I should go there, perhaps.

However, it seems to me that their network connectivity isn’t that great. In particular, IPv6 to their Singapore data centre seems to be flakey. Most of the time, I have no IPv6 reachability to instances spun up in Singapore from my home broadband on StarHub. Sometimes, there is even no IPv6 reachability to Google’s Public DNS. Perhaps there’re some transient problems that persisted on and off across many days.

IPv4 latency isn’t all that great either, not from my workplace, and not that great from my home broadband either. At the former, the latency is very erratic. At the latter, latency is consistently too high for what you’d expect for a Singapore-to-Singapore connection. It turns out to be so because, probably, the traffic goes out of Singapore and comes back again. I think all these will need more testing.

For folks thinking about moving to Linode, I think their servers are great per se. The storage I/O is spectacular. Perhaps their network might work better elsewhere, like Newark, where I did most of the benchmarking.