>I'd also be wary of a host trying to win your business. While wooing you your services might be run on a lightly-loaded backend. Then when the contract's signed they might put you on overloaded main infrastructure.

Wary might be too strong for my taste - getting the best deal is the aim of BOTH sides of the agreement. A practice described in 2nd sentence is borderline in my eyes - timing like Thierry did here to establish ballpark acceptable ranges is prudent:

>>Here is what we found (in sec.):
>>
>>HDD:
>>

min: 0,047
>>avg: 0,107
>>max: 0,462

>>
>>SSD:
>>

min: 0,078
>>avg: 0,096 && 10% less
>>max: 0,125 && 75% less

>>
>>SSD makes response times faster (in avg) and more stable (less variation).

If my task depends on such perf criteria, it is my duty to add a byclause specifying tests and agreed upon measurementsresults. If my sever then runs in "worse" surroundings, I can measure again and either void the contract or force them to change setup. Contract is a meeting of minds+intents, so establishing your needs IMO is your responsibility. At start you circumvent by buying much more of the (still cheap) services with only marginal perf req/tests, starting with 4 digits of cost you test/verify/refine, with not-too-small 5 digits of cost such testing usually will save more money than testing effort costs.

Changes in basic HW usually always lead to speedup (will be interesting when ARM servers compete with i64) but if you are REALLY perf dependant, own HW is still better IMO, even if put in a 3rd company rack.