Cloud Storage Myths: Why Latency Trumps Capacity in 2010
Let’s be honest. The term "Cloud" is getting thrown around by marketing departments faster than a kernel panic on bad RAM. If you are running a serious application—maybe a Magento store or a high-traffic Drupal site—you have likely seen the advertisements: "Unlimited Disk Space," "Elastic Storage," "Store Everything."
It is nonsense.
As a sysadmin who has spent the last week debugging MySQL replication lag on an oversold OpenVZ node, I’m here to tell you that capacity is cheap. Throughput is expensive. Latency is everything. In the Norwegian market, where connectivity to NIX (Norwegian Internet Exchange) is pristine, ruining your speed with cheap storage architecture is a crime against your users.
The "Network Storage" Bottleneck
Many VPS providers today (March 2010) are moving toward massive Storage Area Networks (SAN). The pitch is great: if the compute node dies, your data persists. But here is the reality. Most of these providers are piping storage traffic over standard Gigabit Ethernet, shared with public traffic.
When your database tries to write a transaction, that data has to leave the CPU, traverse the network stack, hit the switch, land on the storage array, write to the disk, and confirm back. That is latency. Milliseconds add up. If you have a busy forum or an e-commerce shop, your iowait will skyrocket.
Pro Tip: Check your current bottleneck. Runiostat -x 1on your Linux box. If your%utilis near 100% but your throughput is low, you are suffering from high seek times or a noisy neighbor on the host node.
The War Story: The Magento Meltdown
Last month, I audited a client hosting a Magento 1.4 store on a budget "Cloud VPS" from a US provider. They had 100GB of space. Great, right? Wrong. The page load times were hitting 6 seconds. The database was choking on simple queries.
The culprit wasn't CPU. It wasn't RAM. It was the disk queue. The provider had hundreds of VMs fighting for the read/write heads of a few SATA drives in a RAID 5 array. RAID 5 is for backups, not for active databases. The write penalty killed them.
The Solution: Local RAID 10 SAS
Until SSDs become affordable enough for mass hosting (the Intel X25-M is promising but still pricey for bulk storage), the gold standard for performance is 15k RPM SAS drives in RAID 10. This configuration strips data for speed and mirrors it for redundancy. No network latency. The disk is physically close to the CPU.
This is why CoolVDS ignores the SAN hype for our primary compute nodes. We use local storage. It’s harder for us to manage, but your MySQL `INSERT` statements execute instantly. We don't optimize for marketing buzzwords; we optimize for physics.
Privacy: The Patriot Act vs. Norwegian Law
Performance isn't the only concern in 2010. We have to talk about where the bits actually live. If you store your customer data on a cloud server in Texas or Virginia, you are subject to the US Patriot Act. This means US authorities can access your data without a court order.
For Norwegian businesses, this is a nightmare for compliance with the Personal Data Act (Personopplysningsloven) and the EU Data Protection Directive (95/46/EC). Datatilsynet (The Norwegian Data Protection Authority) has been very clear about the responsibilities of data controllers.
Hosting locally in Oslo solves two problems:
- Latency: You get <2ms pings to almost anywhere in Norway via NIX.
- Sovereignty: Your data remains under Norwegian jurisdiction. No Safe Harbor loopholes required.
Optimizing for the Hardware You Have
Even on high-performance storage like CoolVDS, you need to tune your software. The default MySQL 5.0/5.1 configurations are often set for tiny memory footprints. If you have the RAM, use it to reduce disk I/O.
Here is a snippet for your /etc/my.cnf to reduce disk writes if you can tolerate losing 1 second of data during a total crash (a worthy trade-off for performance in most web apps):
[mysqld]
# Default is 1 (safest but slowest). Set to 2 to write to OS cache instead.
innodb_flush_log_at_trx_commit = 2
# Give InnoDB room to breathe. Set to 50-70% of available RAM.
innodb_buffer_pool_size = 512M
The Verdict
In 2010, you cannot afford to guess about storage. "Unlimited" usually means "Unusable." You need known seek times, high rotational speeds, and isolation.
At CoolVDS, we use Xen virtualization to ensure strict resource separation—no ballooning memory or stolen CPU cycles. We pair that with local RAID 10 storage to ensure your I/O is yours alone. Don't let your infrastructure be the bottleneck that stalls your growth.
Stop fighting with `iowait`. Deploy a high-performance instance on CoolVDS today and see what real disk speed looks like.