96MB Low End VPS Review Part 55 – VPS.Net
Recently, more and more people start to talk about the idea of “Cloud Computing”, particularly since the Amazon EC2 and Microsoft Azure start to gaining popularity among primarily enterprise customers who has a strong desire for scalability and stability of the platform. Unfortunately for the low end VPS users like you and me, the cost to run such a true cloud set up is more than often prohibitively high, way beyond what hobbyists could afford. VPS.NET, from this perspective, provided an pretty reasonable price point (albeit still a little high in the low end VPS market). Therefore, when I saw the free month offer from VPS.Net on Webhostingtalk.com, I decided to sign up and take a look at how their services is like.
Basic Information and Set Up
As per their advertisement on WHT, here is what you get for a month worth of free services:
As you can see, it is pretty generous in the LEB standard, and what’s more, you can pick up any one of the fifteen locations in the world to sign up for:
Obviously majority of the locations are in US but we have some of the more “bang for the buck” locations such as Tokyo and Singapore, which, due to their expensive bandwidth, are rarely sold at the “low-end” prices.
The sign up process was not exactly the easiest for me as my order was marked as “fraud”, which is the first time I have had encountered such an issue, and in order to prove that I am not fake, this is what I actually had to do:
I am not sure if it was a joke or they really hope someone would take a picture of themselves saying so. In any case, I did not use that option but instead simply sent a scanned copy of my credit card with some of the digits covered. This is actually the very first time that my order was marked as “fraud”, I can only assume that VPS.NET use some more strict anti-fraud measures than what WHMCS comes with.
Furthermore, although it could simply be me forgot to type the promo code when place my order, for some reason I was not credited automatically for the first month. However the billing department was very quick in rectify the issue.
Once I get to the control panel, the first page is a really long one with many items that you can choose from:
In fact, as you can see, the page is so long that I had to take three screenshots to get a view of the complete page. However, as you can see, almost every single functionality that you will ever need with VPS.NET is there. And you could make purchase and ask support from this page too.
However, I think the website could be more personalized and have a different layout based on the kind of service you have with them (VPS, Cloud Hosting, VPN, etc), although I do see the advantage of putting them together: it is not only easier design-wise but is also a good opportunity to sell your customers some additional service.
For the cloud VPS, you will need to create a VPS first and here is how their creation page looks like:
As you can see, the CPU that I had during the review was only 0.6GHz of CPU power, not 1.2GHz as stated on the advertisement. However, RAM size, hard drive size and bandwidth is exactly what is mentioned.
Note that by default, the snapshot option is selected by default, which will cost an extra $5/month. However, you are free to take the option off. There is also options to enable rSync backup and R1Soft backup, which you can select as necessary.
You can also add in additional software packages, with CPanel at a relative cheap price of $10 per month (which you normally get it for 15 by buying directly from the resellers) and the WHMCS cost 7.50 per month, which is also heavily discounted.
After that, you can select the “Cloud”, which I guess would be the region to host your VPS as well as the available zones, once those options are selected, you can also select the operating systems, there are both “bare” OS as well as OS with pre-packaged software for easy deployment. Note that there seems to be only 64 bit OS available, which is not great for small RAM VPS:
One pretty interesting feature is that once you select the Cloud, the system will automatically find the least used zone, although I guess it just means the zone is least used at this time but no guarantee that it will still be the least used zone in future. You can also select some beta templates if you are adventurous.
Note that if you would like to select Windows template, it will cost US$ 7.50 extra per month and there does not seems to be a feature for you to use your own activation key and save that.
I ended up selecting Washington Zone A as my VPS with no backups, and once the VPS is created, here is how it looks like on the dashboard:
You can click on edit to change some of the features of the node by clicking on the edit button:
On top of that, you can also buy some addons. For example, each of the external IPv4 address will cost you a dollar per month. You can also buy server management, dotDefender, Codebase, monitoring and R1Soft services:
The creation of support ticket is also a pretty interesting process. Normally, VPS providers classify tickets by departments (support, sales, abuse, etc), however in the case of VPS.NET, the tickets are created based on the amount they charge and the service level provided:
For example, you can create Free on-Demand ticket which cost you nothing for some of the most basic issues, however it is one issue per ticket and each ticket will last 24 hours. As such, essentially you are restricted to have one free request per day.
Test on the VPS
As mentioned above, the Cloud VPS that I have has 376MB of RAM, 0.6GHz of CPU and 10GB of hard drive. The VPS is provisioned in Washington DC – Zone A. I have installed Debian 6 64 bit for testing purposes as unfortunately the 32 bit version is not available.
uname -a Linux ******* 2.6.32-5-xen-amd64 #1 SMP Thu Nov 3 05:42:31 UTC 2011 x86_64 GNU/Linux
With the system was first installed, about 40MB of RAM was used:
free -m
total used free shared buffers cached
Mem: 371 111 260 0 29 41
-/+ buffers/cache: 40 330
Swap: 1023 0 1023
Note that the total RAM amount shown was 371MB rather than 376MB, which means the kernel is actually using RAM resources in this CPU. This is actually something great for people who would like to play around with kernel modules. Furthermore, note that there is also about 1GB of swap space for this particular VPS, which of course, comes out of the 10GB of hard drive quota that you have, essentially reducing the actual hard drive space to about 9GB.
Top showing the processes running:
top - 01:49:32 up 2 days, 15:01, 1 user, load average: 0.00, 0.00, 0.00
Tasks: 54 total, 1 running, 53 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 380764k total, 114452k used, 266312k free, 29892k buffers
Swap: 1048568k total, 0k used, 1048568k free, 42608k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
975 snmp 20 0 47464 5012 2676 S 0 1.3 0:34.20 snmpd
8305 root 20 0 70460 3332 2624 S 0 0.9 0:00.02 sshd
962 ntp 20 0 38456 2208 1624 S 0 0.6 0:10.00 ntpd
904 root 20 0 117m 2200 1092 S 0 0.6 0:01.18 rsyslogd
8309 root 20 0 19216 2004 1528 S 0 0.5 0:00.01 bash
8317 root 20 0 18932 1280 1004 R 0 0.3 0:00.00 top
977 root 20 0 49168 1144 592 S 0 0.3 0:02.54 sshd
968 root 20 0 22392 860 652 S 0 0.2 0:00.24 cron
1 root 20 0 8352 804 676 S 0 0.2 0:02.74 init
453 root 16 -4 16736 768 384 S 0 0.2 0:00.02 udevd
506 root 18 -2 16732 684 308 S 0 0.2 0:00.00 udevd
509 root 18 -2 16732 684 308 S 0 0.2 0:00.00 udevd
946 root 20 0 3916 628 488 S 0 0.2 0:00.00 acpid
994 root 20 0 5928 624 520 S 0 0.2 0:00.00 getty
995 root 20 0 5928 624 520 S 0 0.2 0:00.00 getty
997 root 20 0 5928 624 520 S 0 0.2 0:00.00 getty
996 root 20 0 5928 620 520 S 0 0.2 0:00.00 getty
And htop output:
About 700MB of hard drive space was used, which is pretty standard for the Debian installation:
df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda1 8.9G 700M 7.8G 9% / tmpfs 186M 0 186M 0% /lib/init/rw udev 168M 80K 167M 1% /dev tmpfs 186M 0 186M 0% /dev/shm
And about 4% of Inodes were used:
df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/xvda1 589824 20237 569587 4% / tmpfs 47595 4 47591 1% /lib/init/rw udev 42770 447 42323 2% /dev tmpfs 47595 1 47594 1% /dev/shm
When the full LNMP stack was loaded, RAM usage went to about 90MB:
free -m
total used free shared buffers cached
Mem: 371 366 5 0 10 265
-/+ buffers/cache: 90 281
Swap: 1023 0 1023
Pretty interesting is the fact that the swap space was not used at all in this case, although most of the time when I have installed the LNMP stack, at least 1MB of swap space was used.
Again, top showing the processes running:
top - 09:44:23 up 13 days, 17:30, 1 user, load average: 0.10, 0.27, 0.36 Tasks: 64 total, 1 running, 63 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 380764k total, 370024k used, 10740k free, 41588k buffers Swap: 1048568k total, 0k used, 1048568k free, 244872k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1127 www 20 0 50124 20m 776 S 0 5.6 0:00.02 nginx 1081 mysql 20 0 52276 6904 2876 S 0 1.8 0:00.02 mysqld 1128 root 20 0 104m 5600 1320 S 0 1.5 0:46.46 php-cgi 1133 www 20 0 104m 5156 876 S 0 1.4 0:00.00 php-cgi 1129 www 20 0 104m 5152 872 S 0 1.4 0:00.00 php-cgi 1130 www 20 0 104m 5152 872 S 0 1.4 0:00.00 php-cgi 1131 www 20 0 104m 5152 872 S 0 1.4 0:00.00 php-cgi 1132 www 20 0 104m 5152 872 S 0 1.4 0:00.00 php-cgi 1090 snmp 20 0 47472 5032 2700 S 0 1.3 0:39.46 snmpd 17218 root 20 0 70496 3356 2652 S 0 0.9 0:00.00 sshd 909 root 20 0 54692 2224 1112 S 0 0.6 0:00.68 rsyslogd 1101 ntp 20 0 38340 2204 1620 S 0 0.6 0:10.94 ntpd 17221 root 20 0 19228 2068 1588 S 0 0.5 0:00.00 bash 17418 root 20 0 19048 1308 1020 R 0 0.3 0:00.00 top 1092 root 20 0 49176 1144 596 S 0 0.3 0:01.23 sshd 1125 root 20 0 29984 960 272 S 0 0.3 0:00.00 nginx 1083 root 20 0 22400 868 664 S 0 0.2 0:00.26 cron
When the full LNMP stack was loaded, about 2.4GB of hard drive space was used:
df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda1 8.9G 2.4G 6.1G 28% / tmpfs 186M 0 186M 0% /lib/init/rw udev 168M 80K 167M 1% /dev tmpfs 186M 0 186M 0% /dev/shm
And 13% of Inodes is used:
df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/xvda1 589824 71683 518141 13% / tmpfs 47595 4 47591 1% /lib/init/rw udev 42770 447 42323 2% /dev tmpfs 47595 1 47594 1% /dev/shm
Uptime shows the VPS is pretty stable:
uptime 01:59:41 up 2 days, 15:11, 1 user, load average: 0.00, 0.00, 0.00
And vmstat shows there is no waiting time on the hard drive:
vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 0 239124 31536 66404 0 0 0 0 4 3 0 0 100 0
Results taken a few days later showed the VPS has no reboot, although it was heavily used as I was installing the LNMP stack:
uptime 09:40:32 up 13 days, 17:27, 1 user, load average: 0.60, 0.49, 0.45
And vmstats shows similar results to the initial readings:
vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 142732 75228 78560 0 0 0 0 3 6 1 0 99 0
CPUinfo shows the VPS have 2 E5620 CPU cores assigned to this VPS.
cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 44 model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz stepping : 2 cpu MHz : 2400.084 cache size : 12288 KB fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nonstop_tsc pni ssse3 cx16 sse4_1 sse4 _2 popcnt hypervisor lahf_lm bogomips : 4800.16 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 44 model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz stepping : 2 cpu MHz : 2400.084 cache size : 12288 KB fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nonstop_tsc pni ssse3 cx16 sse4_1 sse4 _2 popcnt hypervisor lahf_lm bogomips : 4800.16 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management:
Although it does not seem to be throttled from here, the 0.6GHz CPU definitely told us this is not something that we can use at its full power.
Meminfo did not show anything too interesting:
cat /proc/meminfo MemTotal: 380764 kB MemFree: 9720 kB Buffers: 41596 kB Cached: 245372 kB SwapCached: 0 kB Active: 80264 kB Inactive: 245144 kB Active(anon): 15404 kB Inactive(anon): 23128 kB Active(file): 64860 kB Inactive(file): 222016 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 1048568 kB SwapFree: 1048568 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 38440 kB Mapped: 9688 kB Shmem: 92 kB Slab: 17472 kB SReclaimable: 12492 kB SUnreclaim: 4980 kB KernelStack: 648 kB PageTables: 2576 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 1238948 kB Committed_AS: 121288 kB VmallocTotal: 34359738367 kB VmallocUsed: 6100 kB VmallocChunk: 34359731336 kB HardwareCorrupted: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 385024 kB DirectMap2M: 0 kB
And time sync:
time sync real 0m0.012s user 0m0.000s sys 0m0.000s
For the disk I/O, I was expecting something that cost this much per month would give some pretty good performance, unfortunatey it does not seem to be the case. While the performance is probably OK for majority of the users, it is by no means too impressive.
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync 16384+0 records in 16384+0 records out 1073741824 bytes (1.1 GB) copied, 22.0811 s, 48.6 MB/s
Testing again showed slightly better results:
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync 16384+0 records in 16384+0 records out 1073741824 bytes (1.1 GB) copied, 20.5278 s, 52.3 MB/s
Even the ioping is not that stable as well:
ioping -c 10 . 4096 bytes from . (ext3 /dev/xvda1): request=1 time=0.5 ms 4096 bytes from . (ext3 /dev/xvda1): request=2 time=1.0 ms 4096 bytes from . (ext3 /dev/xvda1): request=3 time=0.5 ms 4096 bytes from . (ext3 /dev/xvda1): request=4 time=82.9 ms 4096 bytes from . (ext3 /dev/xvda1): request=5 time=0.5 ms 4096 bytes from . (ext3 /dev/xvda1): request=6 time=0.5 ms 4096 bytes from . (ext3 /dev/xvda1): request=7 time=119.1 ms 4096 bytes from . (ext3 /dev/xvda1): request=8 time=0.4 ms 4096 bytes from . (ext3 /dev/xvda1): request=9 time=0.4 ms 4096 bytes from . (ext3 /dev/xvda1): request=10 time=0.4 ms --- . (ext3 /dev/xvda1) ioping statistics --- 10 requests completed in 9207.7 ms, 49 iops, 0.2 mb/s min/avg/max/mdev = 0.4/20.6/119.1/41.0 ms
As you can see, for the “good” roundtrips, the ping time is less than half a ms, however sometimes it could go as high as more than 100ms, which is not really acceptable.
Testing again showed more consistent results, however it could be just a “lucky” one:
ioping -c 10 . 4096 bytes from . (ext3 /dev/xvda1): request=1 time=0.3 ms 4096 bytes from . (ext3 /dev/xvda1): request=2 time=0.5 ms 4096 bytes from . (ext3 /dev/xvda1): request=3 time=0.9 ms 4096 bytes from . (ext3 /dev/xvda1): request=4 time=0.6 ms 4096 bytes from . (ext3 /dev/xvda1): request=5 time=0.4 ms 4096 bytes from . (ext3 /dev/xvda1): request=6 time=0.4 ms 4096 bytes from . (ext3 /dev/xvda1): request=7 time=12.7 ms 4096 bytes from . (ext3 /dev/xvda1): request=8 time=0.5 ms 4096 bytes from . (ext3 /dev/xvda1): request=9 time=0.9 ms 4096 bytes from . (ext3 /dev/xvda1): request=10 time=0.5 ms --- . (ext3 /dev/xvda1) ioping statistics --- 10 requests completed in 9019.2 ms, 562 iops, 2.2 mb/s min/avg/max/mdev = 0.3/1.8/12.7/3.7 ms
The network speed is really solid though, for download I was able to push to close to 30MB/s:
wget cachefly.cachefly.net/100mb.test -O /dev/null --2012-07-05 09:46:05-- 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: a€?/dev/nulla€ 100%[=======================================================================================================================================>] 104,857,600 29.0M/s in 3.4s 2012-07-05 09:46:09 (29.0 MB/s) - a€?/dev/nulla€
Testing again showed even better results:
wget cachefly.cachefly.net/100mb.test -O /dev/null --2012-07-05 09:44:59-- 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: a€?/dev/nulla€ 100%[======================================>] 104,857,600 35.8M/s in 2.8s 2012-07-05 09:45:02 (35.8 MB/s) - a€?/dev/nulla€
For the upload, however, is a lot less impressive. Here is the results from a Quickweb VPS in Chicago, IL:
wget 173.255.141.45/100mb.test -O /dev/null --2012-07-05 09:49:49-- http://173.255.141.45/100mb.test Connecting to 173.255.141.45:80... connected. HTTP request sent, awaiting response... 200 OK Length: 104857600 (100M) [application/octet-stream] Saving to: `/dev/null' 100%[======================================>] 104,857,600 2.64M/s in 67s 2012-07-05 09:50:57 (1.49 MB/s) - `/dev/null' saved [104857600/104857600]
On the West Coast, my Quickweb VPS in Los Angeles, CA, showed even worse results:
wget 173.255.141.45/100mb.test -O /dev/null --2012-07-04 21:51:22-- http://173.255.141.45/100mb.test Connecting to 173.255.141.45:80... connected. HTTP request sent, awaiting response... 200 OK Length: 104857600 (100M) [application/octet-stream] Saving to: `/dev/null' 100%[======================================>] 104,857,600 1.12M/s in 2m 0s 2012-07-04 21:53:29 (851 KB/s) - `/dev/null' saved [104857600/104857600]
Finally, my XenVZ VPS in Maindenhead, UK, shows the slowest speed, probably due to the longest distance:
wget 173.255.141.45/100mb.test -O /dev/null --2012-07-05 09:58:46-- http://173.255.141.45/100mb.test Connecting to 173.255.141.45:80... connected. HTTP request sent, awaiting response... 200 OK Length: 104857600 (100M) [application/octet-stream] Saving to: `/dev/null' 100%[======================================>] 104,857,600 327K/s in 6m 37s 2012-07-05 10:05:23 (258 KB/s) - `/dev/null' saved [104857600/104857600]
I was having a tough time getting the benchmark tests done because the free version of Geekbench is not available on the 64 bit systems and unfortunately VPS.NET only has 64 bit OS available for Linux. Therefore, I had to use UnixBench to do my benchmarking:
# # # # # # # ##### ###### # # #### # #
# # ## # # # # # # # ## # # # # #
# # # # # # ## ##### ##### # # # # ######
# # # # # # ## # # # # # # # # #
# # # ## # # # # # # # ## # # # #
#### # # # # # ##### ###### # # #### # #
Version 5.1.3 Based on the Byte Magazine Unix Benchmark
Multi-CPU version Version 5 revisions by Ian Smith,
Sunnyvale, CA, USA
January 13, 2011 johantheghost at yahoo period com
1 x Dhrystone 2 using register variables 1 2 3 4 5 6 7 8 9 10
1 x Double-Precision Whetstone 1 2 3 4 5 6 7 8 9 10
1 x Execl Throughput 1 2 3
1 x File Copy 1024 bufsize 2000 maxblocks 1 2 3
1 x File Copy 256 bufsize 500 maxblocks 1 2 3
1 x File Copy 4096 bufsize 8000 maxblocks 1 2 3
1 x Pipe Throughput 1 2 3 4 5 6 7 8 9 10
1 x Pipe-based Context Switching 1 2 3 4 5 6 7 8 9 10
1 x Process Creation 1 2 3
1 x System Call Overhead 1 2 3 4 5 6 7 8 9 10
1 x Shell Scripts (1 concurrent) 1 2 3
1 x Shell Scripts (8 concurrent) 1 2 3
2 x Dhrystone 2 using register variables 1 2 3 4 5 6 7 8 9 10
2 x Double-Precision Whetstone 1 2 3 4 5 6 7 8 9 10
2 x Execl Throughput 1 2 3
2 x File Copy 1024 bufsize 2000 maxblocks 1 2 3
2 x File Copy 256 bufsize 500 maxblocks 1 2 3
2 x File Copy 4096 bufsize 8000 maxblocks 1 2 3
2 x Pipe Throughput 1 2 3 4 5 6 7 8 9 10
2 x Pipe-based Context Switching 1 2 3 4 5 6 7 8 9 10
2 x Process Creation 1 2 3
2 x System Call Overhead 1 2 3 4 5 6 7 8 9 10
2 x Shell Scripts (1 concurrent) 1 2 3
2 x Shell Scripts (8 concurrent) 1 2 3
========================================================================
BYTE UNIX Benchmarks (Version 5.1.3)
System: xxxxx GNU/Linux
OS: GNU/Linux -- 2.6.32-5-xen-amd64 -- #1 SMP Thu Nov 3 05:42:31 UTC 2011
Machine: x86_64 (unknown)
Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
CPU 0: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (4800.2 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
CPU 1: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (4800.2 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
10:41:26 up 2 days, 15:53, 1 user, load average: 0.00, 0.10, 0.32; runlevel 2
------------------------------------------------------------------------
Benchmark Run: Wed Jun 13 2012 10:41:26 - 11:09:46
2 CPUs in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 22462898.5 lps (10.0 s, 7 samples)
Double-Precision Whetstone 2989.4 MWIPS (9.8 s, 7 samples)
Execl Throughput 1246.5 lps (29.8 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 200141.5 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 52833.0 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 566341.7 KBps (30.0 s, 2 samples)
Pipe Throughput 341031.5 lps (10.0 s, 7 samples)
Pipe-based Context Switching 67122.6 lps (10.0 s, 7 samples)
Process Creation 2612.3 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 3641.8 lpm (60.3 s, 2 samples)
Shell Scripts (8 concurrent) 684.5 lpm (60.1 s, 2 samples)
System Call Overhead 415802.5 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 22462898.5 1924.8
Double-Precision Whetstone 55.0 2989.4 543.5
Execl Throughput 43.0 1246.5 289.9
File Copy 1024 bufsize 2000 maxblocks 3960.0 200141.5 505.4
File Copy 256 bufsize 500 maxblocks 1655.0 52833.0 319.2
File Copy 4096 bufsize 8000 maxblocks 5800.0 566341.7 976.5
Pipe Throughput 12440.0 341031.5 274.1
Pipe-based Context Switching 4000.0 67122.6 167.8
Process Creation 126.0 2612.3 207.3
Shell Scripts (1 concurrent) 42.4 3641.8 858.9
Shell Scripts (8 concurrent) 6.0 684.5 1140.8
System Call Overhead 15000.0 415802.5 277.2
========
System Benchmarks Index Score 472.5
------------------------------------------------------------------------
Benchmark Run: Wed Jun 13 2012 11:09:46 - 11:38:19
2 CPUs in system; running 2 parallel copies of tests
Dhrystone 2 using register variables 44472707.3 lps (10.0 s, 7 samples)
Double-Precision Whetstone 5952.9 MWIPS (10.0 s, 7 samples)
Execl Throughput 2477.7 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 290836.0 KBps (30.1 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 80112.5 KBps (30.1 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 849356.4 KBps (30.2 s, 2 samples)
Pipe Throughput 671592.6 lps (10.0 s, 7 samples)
Pipe-based Context Switching 129186.7 lps (10.0 s, 7 samples)
Process Creation 4884.6 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 5412.3 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 708.4 lpm (60.1 s, 2 samples)
System Call Overhead 771261.6 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 44472707.3 3810.9
Double-Precision Whetstone 55.0 5952.9 1082.3
Execl Throughput 43.0 2477.7 576.2
File Copy 1024 bufsize 2000 maxblocks 3960.0 290836.0 734.4
File Copy 256 bufsize 500 maxblocks 1655.0 80112.5 484.1
File Copy 4096 bufsize 8000 maxblocks 5800.0 849356.4 1464.4
Pipe Throughput 12440.0 671592.6 539.9
Pipe-based Context Switching 4000.0 129186.7 323.0
Process Creation 126.0 4884.6 387.7
Shell Scripts (1 concurrent) 42.4 5412.3 1276.5
Shell Scripts (8 concurrent) 6.0 708.4 1180.6
System Call Overhead 15000.0 771261.6 514.2
========
System Benchmarks Index Score 796.1
For half a core of CPU, this speed is not bad, but nowhere impressive either. Unfortuantely, I could not repeat the test as for some reason, the Unixbench tests seem to get stuck afterwards:
# # # # # # # ##### ###### # # #### # #
# # ## # # # # # # # ## # # # # #
# # # # # # ## ##### ##### # # # # ######
# # # # # # ## # # # # # # # # #
# # # ## # # # # # # # ## # # # #
#### # # # # # ##### ###### # # #### # #
Version 5.1.3 Based on the Byte Magazine Unix Benchmark
Multi-CPU version Version 5 revisions by Ian Smith,
Sunnyvale, CA, USA
January 13, 2011 johantheghost at yahoo period com
1 x Dhrystone 2 using register variables 1 2 3 4 5 6 7 8 9 10
1 x Double-Precision Whetstone 1
After a few tries, I had to give up on testing any further.
Customer Service and Support
The ticket support system used by VPS.NET, as mentioned above, is based on the category of the ticket and I have only submitted tickets via their Free on Demand category, which I was thinking that probably takes the lowest priority. However, the ticket was actually responded pretty fast and a ticket that I have submitted at 22:18EDT was responded 4 minutes later with the exact response to the questions, which I think is pretty good:
Conclusion
VPS.NET is one of that I would consider as a “cloud” provider in the relative budget category. However, while the “cloud” set up may appear to customers who require long-term stability and scaling, I do not actually found the performance to be a lot better than the regular VPS providers. The network has great download speed but the upload speed is probably less than satisfactory, disk I/O is good but is not too impressive. As such, unless you are an enterprise customer who really demands high availability and stability over everything else, I think it is better to spend 20 per month on a non-cloud VPS that is a lot more powerful.
Man, just to inform you, you can use Geekbench 32-bit installing the ia32-libs package.
Or if you are in the new multiarch scheme, for the new Ubuntu systems, you can install these libs
apt-get install libc6:i386 libgcc1:i386 gcc-4.6-base:i386 libstdc++5:i386 libstdc++6:i386
The last one, is the ’5′ or ’6′, it depends of your distro
@Anonymous: Thanks for the tip!
Pingback: 96MB Low End VPS Review Part 56–VM Storm VPS - 96MB.com