The Shared Hosting Model is Dead. Long Live the VDS.
Today marks the release of WordPress 3.0 "Thelonious." It is a monumental shift. The merging of WPMU (Multi-User) into core and the introduction of Custom Post Types transforms WordPress from a blog engine into a full-fledged Content Management System (CMS).
But there is a problem. This new power comes with weight. If you are running a serious Norwegian business site on a crowded shared server with 500 other clients, your site is going to crawl. The standard Apache 2.2 prefork configuration, gasping for RAM, cannot handle the concurrent connections required by a heavy WP 3.0 installation.
I have spent the last week migrating high-traffic portals from traditional LAMP stacks to high-performance Virtual Dedicated Servers. The results? We dropped load times from 4.5 seconds to 0.8 seconds. Here is the exact stack we used.
1. Stop Asking Apache to Do Everything
Apache is flexible, but it is heavy. Every connection spawns a process that consumes significant memory. When traffic spikes, your server swaps to disk, and performance falls off a cliff.
The solution in 2010 is not to abandon Apache, but to put a bouncer in front of it: Nginx.
By placing Nginx (specifically version 0.7.x or the new 0.8 stable) as a reverse proxy on port 80, you let it handle all the static files (images, CSS, JS). It serves these with virtually zero CPU load. It only passes the heavy PHP requests to Apache on the backend.
The Configuration Strategy:
server {
listen 80;
server_name example.no;
root /var/www/example.no/public_html;
# Serve static files directly
location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ {
expires max;
}
# Pass PHP to Apache
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
2. The Secret Weapon: APC (Alternative PHP Cache)
If you are not using an opcode cache, you are wasting CPU cycles. Without it, PHP must read, parse, and compile your scripts into opcodes for every single request.
Installing APC (currently version 3.1.3) stores these compiled opcodes in shared memory. The execution bypasses the compiler entirely. For a complex application like WordPress 3.0, this can increase throughput by 300%.
Pro Tip: Don't just install it; tune it. Open yourphp.iniorapc.iniand ensure you allocate enough memory segments. Setapc.shm_size = 64Mor higher depending on your VDS RAM.
3. Database Tuning: The InnoDB Buffer Pool
With WordPress 3.0, the database interactions are more complex. While MyISAM is the default storage engine for MySQL 5.1, it suffers from table-level locking. If one user writes to a table, no one else can read from it until the write is done.
We recommend migrating your tables to InnoDB, which supports row-level locking. This is crucial for sites with comments or multiple editors.
However, InnoDB is useless if you don't tune the innodb_buffer_pool_size. This setting determines how much data MySQL caches in memory. On a CoolVDS instance with 4GB RAM, do not leave this at the default 8MB. Set it to 50-70% of your available RAM if the database is the primary function.
4. The "CoolVDS" Factor: Why Infrastructure Matters
You can tweak configurations all day, but you cannot code your way out of bad hardware or noisy neighbors.
This is where virtualization technology becomes the differentiator. Many budget providers use OpenVZ and oversell resources. They promise you 512MB RAM, but it's "burst" memory that isn't there when you need it.
At CoolVDS, we use KVM (Kernel-based Virtual Machine) virtualization. This ensures that the RAM and CPU cores assigned to your instance are yours. They are hard-locked. No stealing.
Furthermore, we tackle the biggest bottleneck in hosting: Disk I/O. While standard hosting relies on slow SATA drives spinning at 7200 RPM, we are rolling out Enterprise SSD tiers and high-performance RAID-10 SAS arrays. For a database-heavy application like WordPress, the difference in random Read/Write speeds is not just noticeable; it is transformative.
5. Local Latency and Norwegian Compliance
If your target audience is in Oslo, Bergen, or Trondheim, hosting your server in Texas is a strategic error. The speed of light is a hard limit. A round trip from Norway to the US takes 100-150ms. To the NIX (Norwegian Internet Exchange) in Oslo, it takes 2-10ms.
Google has already hinted that site speed is a ranking factor. Lower latency equals better SEO.
Additionally, we must consider the Personopplysningsloven (Personal Data Act). Keeping your customer data within Norway or the EEA simplifies compliance with the Data Inspectorate (Datatilsynet) and ensures you aren't caught in legal limbo regarding data export.
Final Thoughts
WordPress 3.0 is a fantastic leap forward, but it requires a mature hosting environment. Don't let a bloated shared host kill your launch. Optimize your stack, cache your opcode, and sit close to the metal.
Ready to see what WP 3.0 can really do? Deploy a KVM-powered CoolVDS instance in Oslo today. We guarantee the dedicated resources you pay for.