[GRLUG] VPS disagreement

[Michael Mol]

On 03/16/2013 03:27 PM, Tim Schmidt wrote:
> On Sat, Mar 16, 2013 at 11:18 AM, desert frag <desertfrag at yahoo.com> wrote:
>> The results have consistently shown one server to produce lower cpu %
>> utilization scores than another over the past few days.  Since you're
>> suggesting one node is more taxed than another then they haven't been up
>> front.  I will mention this in mind in my reply.  Thank you.
> 
> I also have a chicagovps account - 3Gb ram / 100Gb disk / 2.5TB
> transfer @ $21 / quarter - and they're very up front about the fact
> that they use SolusVM - a linux containers based solution.  The
> resources on each host under Solus are shared much more freely than
> with hypervisors like Xen or KVM.  Ram is overcomitted and deduped,
> just like the disks are.  Everyone's processes run on the same kernel
> - though you shouldn't be able to break out of your container to see
> what others are running.
> 
> If you're looking for something that does cycle-perfect emulation and
> guarantees isolated performance, look into Linode or similar.  Their
> prices, however, are MUCH higher.

Indeed. $40/yr is insanely cheap. $3/mo doesn't get you much of anything...

I'm very fond of prgmr.com, and have used them for a few years, now.
Their pricing is listed fully on their website, but it's intentionally
simple:

"An easy to understand price schedule: $4/month per account, and
$1/month for every 64MiB ram. Please note; this means all plans come
with $4/month worth of support."

They don't say it there, but their per-VM CPU allotment is directly
proportional to RAM allotment; a machine with 1GB of RAM is guaranteed a
minimum number of CPU tickets X, and a machine with 2GB of of RAM is
guaranteed a minimum number of CPU tickets 2X. Roughly speaking, this
means that--on a loaded host server--the machine with twice the RAM gets
twice the CPU guaranteed it. And when nobody else is using the CPU, you
get it all.

In general practice, on a web server, CPU shouldn't make a huge
difference. You cache as much as you can so you don't need to consume
resource to regenerate what you've served before...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20130316/7d4ed1f9/attachment.pgp>