Re: Recommended/Not Recommended Hosts?

Josh,

> Pure curiosity on my part here ... I use EC2 a bit, tho not as much as
> the serious users. A few large and small instances on all the time, and
> I boot up new ones for shorter periods all the time. First - I've
> never had any issue getting my instances fulfilled right away (I always
> use EAST-C, but perhaps other datacenters are generally more full, or
> you are trying to boot up many tens of servers at once?).

Yeah, the two issues I've had are (a) requisitioning high-end instances
(like 32G/16core instances) and (b) allocating a lot at once. Sometimes
instances just "aren't available" and there's no way to find out when
they will be available.

> Also, when you say they are slow, do you mean in terms of $/cycle,
> or you wish you had burst access to other users unused cycles like on
> some other vps offerings? something else?

I mean that if you have an 8core/16GB instance, the actual processing
throughput you get is about 1/6 to 1/4 that of a new HP DL380 machine
with 8cores and 16GB. So you really need 4x as many EC2 instances to
match bare metal. Partly this is due to CPU-stealing, and partly to
erratic and lag-prone I/O, and partly to the fact that a lot of machines
in the EC2 pool are 4 years old.

> I like the bundle of offerings that AWS provides (EBS, especially), and
> I've personally had great experience w/them (fwiw I've also had great
> experience w/slicehost) -- but if I am getting missing out on how
> they're screwing me, for example by stealing my CPU, I'd definitely love
> to learn more.

On EC2, other VMs on the same hardware are permitted to "steal" portions
of the CPU which are allocated to you. So at any given time, you may
have as little as 50% of the CPUs you're being billed for. And, when
CPU availability is fluctuating up and down (as it does on EC2), real
throughput tends to be based on the slowest second rather than peak
availablity. Most Linux apps, especially databases, do quite poorly
with erratic resource availability.

--Josh