BuyVM (California / OpenVZ) Jan 2011 Benchmarks | VPS Benchmarks
 

BuyVM (California / OpenVZ) Jan 2012 Benchmarks

Background:
I have done many posts in regards to a BuyVM review.. however I decided to do an update since it’s January, the new year, and the team at BuyVM seems to be active with kernel upgrades again. My main IRC box rebooted a few days ago and this idle BuyVM box has over 30 days uptime.. interesting!

Price: $15 per year

Plan:

  • 128mb guaranteed RAM
  • 256mb burstable RAM
  • 10 gigabytes disk space
  • 500 gigabytes network transfer
  • San Jose, California data center
  • 1 IPv4 address, 16 IPv6

Hardware:

# cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 26
model name	: Intel(R) Xeon(R) CPU           L5520  @ 2.27GHz
stepping	: 5
cpu MHz		: 2266.694
cache size	: 4096 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 4
apicid		: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc pni ssse3 cx16 sse4_1 sse4_2 popcnt lahf_lm
bogomips	: 4533.38
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management:

Hardware Benchmarks:

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: cdn: GNU/Linux
   OS: GNU/Linux -- 2.6.32-238.12.1.el5.pony6-1 -- #3 SMP Fri Jun 3 16:37:31 PDT 2011
   Machine: i686 (unknown)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   CPU 0: Intel(R) Xeon(R) CPU L5520 @ 2.27GHz (4533.4 bogomips)
          Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
   16:06:04 up 38 days,  6:44,  1 user,  load average: 0.13, 0.03, 0.01; runlevel 2

------------------------------------------------------------------------
Benchmark Run: Fri Jan 13 2012 16:06:04 - 16:34:05
1 CPU in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       10070923.2 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     2317.2 MWIPS (9.8 s, 7 samples)
Execl Throughput                               1828.0 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        273247.4 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           73735.8 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        641887.1 KBps  (30.0 s, 2 samples)
Pipe Throughput                              601409.7 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 143925.2 lps   (10.0 s, 7 samples)
Process Creation                               5065.2 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   2167.1 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    300.5 lpm   (60.5 s, 2 samples)
System Call Overhead                         538750.3 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   10070923.2    863.0
Double-Precision Whetstone                       55.0       2317.2    421.3
Execl Throughput                                 43.0       1828.0    425.1
File Copy 1024 bufsize 2000 maxblocks          3960.0     273247.4    690.0
File Copy 256 bufsize 500 maxblocks            1655.0      73735.8    445.5
File Copy 4096 bufsize 8000 maxblocks          5800.0     641887.1   1106.7
Pipe Throughput                               12440.0     601409.7    483.4
Pipe-based Context Switching                   4000.0     143925.2    359.8
Process Creation                                126.0       5065.2    402.0
Shell Scripts (1 concurrent)                     42.4       2167.1    511.1
Shell Scripts (8 concurrent)                      6.0        300.5    500.9
System Call Overhead                          15000.0     538750.3    359.2
                                                                   ========
System Benchmarks Index Score                                         513.8

ioping default:

Virtuzzo or OpenVZ Virtualisation detected
**********************************
dd (sequential disk speed test)...
**********************************
dd if=/dev/zero of=testfilex bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 7.1301 s, 151 MB/s

************************
starting ioping tests...
***************************************************
ioping disk I/O test (default 1MB working set)
***************************************************
disk I/O: /
--- / (simfs /dev/simfs) ioping statistics ---
5 requests completed in 4033.4 ms, 909 iops, 3.6 mb/s
min/avg/max/mdev = 0.1/1.1/4.5/1.7 ms

**********************************************
seek rate test (default 1MB working set)
**********************************************
seek rate: /
--- / (simfs /dev/simfs) ioping statistics ---
350 requests completed in 3004.1 ms, 839 iops, 3.3 mb/s
min/avg/max/mdev = 0.1/1.2/55.8/4.5 ms

**********************************************
sequential test (default 1MB working set)
**********************************************
-----------------------
sequential: /
--- / (simfs /dev/simfs) ioping statistics ---
145 requests completed in 3009.4 ms, 69 iops, 17.3 mb/s
min/avg/max/mdev = 7.2/14.4/200.2/17.6 ms
-----------------------
sequential cached I/O: /
--- / (simfs /dev/simfs) ioping statistics ---
367 requests completed in 3000.0 ms, 6594 iops, 1648.4 mb/s
min/avg/max/mdev = 0.1/0.2/0.6/0.0 ms

ioping custom:

Virtuzzo OR OpenVZ Virtualisation detected
Run custom request size 4 32 64 256 (KB) test ? [y/n]: y

################################
ioping disk I/O test
(custom 4 32 64 256 (KB) request size)
################################

***************************************
[/] ioping disk I/O test: 4K test
***************************************
--- / (simfs /dev/simfs) ioping statistics ---
5 requests completed in 4072.3 ms, 115 iops, 0.4 mb/s
min/avg/max/mdev = 0.1/8.7/34.9/13.5 ms

***************************************
[/] ioping disk I/O test: 32K test
***************************************
--- / (simfs /dev/simfs) ioping statistics ---
5 requests completed in 4044.1 ms, 294 iops, 9.2 mb/s
min/avg/max/mdev = 1.2/3.4/11.5/4.1 ms

***************************************
[/] ioping disk I/O test: 64K test
***************************************
--- / (simfs /dev/simfs) ioping statistics ---
5 requests completed in 4045.3 ms, 302 iops, 18.9 mb/s
min/avg/max/mdev = 2.2/3.3/5.1/1.1 ms

***************************************
[/] ioping disk I/O test: 256K test
***************************************
--- / (simfs /dev/simfs) ioping statistics ---
5 requests completed in 4084.2 ms, 90 iops, 22.6 mb/s
min/avg/max/mdev = 7.5/11.1/23.0/6.0 ms

################################
ioping seek rate test
(custom 4 32 64 256 (KB) request size)
################################

***************************************
[/] ioping seek rate test: 4K test
***************************************
--- / (simfs /dev/simfs) ioping statistics ---
321 requests completed in 3006.9 ms, 744 iops, 2.9 mb/s
min/avg/max/mdev = 0.1/1.3/104.4/8.4 ms

***************************************
[/] ioping seek rate test: 32K test
***************************************
--- / (simfs /dev/simfs) ioping statistics ---
298 requests completed in 3001.9 ms, 316 iops, 9.9 mb/s
min/avg/max/mdev = 0.0/3.2/56.4/6.8 ms

***************************************
[/] ioping seek rate test: 64K test
***************************************
--- / (simfs /dev/simfs) ioping statistics ---
313 requests completed in 3005.9 ms, 311 iops, 19.5 mb/s
min/avg/max/mdev = 1.8/3.2/30.1/3.1 ms

***************************************
[/] ioping seek rate test: 256K test
***************************************
--- / (simfs /dev/simfs) ioping statistics ---
159 requests completed in 3009.7 ms, 87 iops, 21.7 mb/s
min/avg/max/mdev = 6.6/11.5/60.4/7.1 ms

100mb Test Files:

# wget -O /dev/null cachefly.cachefly.net/100mb.test
--2012-01-13 16:52:32--  http://cachefly.cachefly.net/100mb.test
Resolving cachefly.cachefly.net... 205.234.175.175
Connecting to cachefly.cachefly.net|205.234.175.175|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: “/dev/null”

100%[===================================================================================================>] 104,857,600 44.1M/s   in 2.3s    

2012-01-13 16:52:34 (44.1 MB/s) - “/dev/null” saved [104857600/104857600]

# wget -O /dev/null tokyo1.linode.com/100MB-tokyo.bin
--2012-01-13 16:53:49--  http://tokyo1.linode.com/100MB-tokyo.bin
Resolving tokyo1.linode.com... 106.187.33.12
Connecting to tokyo1.linode.com|106.187.33.12|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: “/dev/null”

100%[===================================================================================================>] 104,857,600 3.11M/s   in 35s     

2012-01-13 16:54:24 (2.84 MB/s) - “/dev/null” saved [104857600/104857600]

Conclusion:
If price was your only choice in shopping for a virtual private server, just go with BuyVM. However, BuyVM usually keeps stock pretty low. BuyVM claims this is “natural” with somebody going through billing, removing outdated customer VPS accounts, consolidating them and offering them to the public. However, if that was true, every single rumor from Francisco about upcoming stock would not be a rumor and that date would have stock being released to the public. I do think, even though I do not have a problem with it, that BuyVM intentionally restricts stock from the public.

This keeps servers filled and overhead paid for, but keeps perspective customers scratching at the door wanting to be let in while existing customers and customers who made their additional purchases after waiting on stock will rub in the “victory” to those perspective customers more and it’s a pretty decent marketing strategy that works time after time because nobody will say anything about BuyVM nodes rebooting due to a kernel upgrade or call out Francisco about a more definitive stock release date due to this strategy.

This is not an attack or any kind of negative criticism. I’ve just had this observation for well over two years and nobody has yet answered it for me. Francisco has batted at the observation, mentioning the process the billing guy takes to make sure stock being released to the public is supposed to be released, but Francisco waves off about “stock days” being coordinated but how else are you going to release 30 – 40 VPS accounts all at once and not say they are coordinated?

Got something to say? Go for it!

 

DDoS Hosting Solutions