The Database Is Always The Bottleneck
I still remember the first time a client of mine got featured on a major news portal here in Norway. It wasn't VG or Dagbladet, but a niche tech aggregation site. Traffic spiked 500% in ten minutes. The web servers (running Apache 2.2) didn't even flinch. But the site went dark.
Why? Because the database layer choked. Connection timeouts, locked tables, and a load average that spiked to 40.0 on a dual-core box.
If you are running a default installation of MySQL 5.1 on CentOS or Debian Lenny, you are running a setup designed for a hobby site, not a business-critical application. In the Nordic hosting market, where we pride ourselves on stability and speed, relying on defaults is negligence.
MyISAM vs. InnoDB: The Locking War
Most default installations still lean heavily on MyISAM. For years, it was the standard. It's fast for reads, sure. But here is the ugly truth: MyISAM uses table-level locking.
Imagine a queue at a grocery store in Oslo. In a MyISAM world, every time someone wants to pay (write data), the entire store closes its doors until that one person is done. Nobody enters, nobody leaves. On a high-traffic site with comments, orders, or session writes, this is suicide.
Pro Tip: Stop using MyISAM for anything other than read-only lookup tables. Switch to InnoDB. It supports row-level locking (only the specific row being written is locked) and transactions (ACID compliance).
The my.cnf Directives That Actually Matter
Open your /etc/my.cnf. If you haven't touched it, you're likely wasting 90% of your server's RAM while MySQL starves. Here are the adjustments I make on every CoolVDS instance before it goes into production.
1. innodb_buffer_pool_size
This is the single most critical setting for InnoDB. It determines how much data and indexes are cached in memory. If this is too low, your server has to hit the physical disk for every query. In 2010, disk I/O is expensive.
[mysqld]
# If you have a dedicated DB server with 4GB RAM:
innodb_buffer_pool_size = 2G
# If you are on a smaller VPS sharing web/db:
innodb_buffer_pool_size = 512M2. query_cache_size
There is a lot of debate about the Query Cache. In my experience with Magento and Drupal setups, it helps, but don't go crazy. A cache that is too large (over 512MB) can actually cause performance degradation due to invalidation overhead.
query_cache_size = 64M
query_cache_type = 1
query_cache_limit = 2M3. max_connections
Don't let Apache spawn more processes than MySQL can handle. If you hit the Too many connections error, bump this up—but ensure you have the RAM to back it.
max_connections = 300The Hardware Reality: Spindles vs. Solid State
We are at a turning point in server hardware. Most hosting providers in Europe are still cramming you onto SATA II drives spinning at 7,200 RPM. When your database gets hit with random I/O requests, those mechanical arms just can't keep up. You see this as "iowait" in top.
This is where the architecture matters. At CoolVDS, we don't oversell our storage backend. While SSDs (like the Intel X25 series) are becoming available for enterprise caching, even a properly configured RAID-10 array with 15k SAS drives can drastically reduce latency compared to standard SATA VPS nodes.
If your application requires heavy write throughput, you cannot afford to be on a node with "noisy neighbors" stealing your I/O operations.
Data Sovereignty and Latency
Hosting your database in the US (like on EC2) while your customers are in Oslo is a latency penalty you don't need to pay. Light takes time to travel. A ping from Oslo to Virginia is roughly 100-120ms. A ping to a local data center connected to NIX (Norwegian Internet Exchange) is 2-5ms.
Furthermore, under the Personopplysningsloven (Personal Data Act), keeping Norwegian user data within the EEA is simply safer from a compliance standpoint. The Data Inspectorate (Datatilsynet) is becoming increasingly strict about how data is handled across borders.
The CoolVDS Difference
We use Xen HVM virtualization. Unlike OpenVZ, which many budget hosts use to oversell resources, Xen ensures that the RAM and CPU scheduler you pay for are actually yours. When you tune your `innodb_buffer_pool_size` on CoolVDS, that memory is reserved for you, not swapped out to disk because another customer is running a backup script.
If you are tired of Waiting for table lock errors and sluggish page loads, it is time to get serious about your infrastructure.
Don't let slow I/O kill your user experience. SSH into a high-performance instance on CoolVDS today and feel the difference raw power makes.