After my post on increasing WordPress Performance, I’ve been helping several other people with their overloaded website.
The most unique probably is the one owned by (let’s call him) Mr. King.

Mr. King has got a very popular website. PageRank 2 only, but since it’s a niche rarely targeted by others, people are flocking there anyway.
He’s making (my guess) thousands of dollars every month, just from Google AdSense shown on his website.

However, the popularity brings other problems. His powerful server (I think it’s a quad core,with 4 GB RAM) was constantly overloaded.
After I optimized the server, it’s working fine now.

Except for the static pages.

First, a little bit about “static” page in WordPress. It’s not really static actually, it’s dynamically generated. In itself it’s not a problem.
However, when you utilize WordPress’ permalink feature, essential to make your website more visible on Google, **and** you have thousands of pages; then it started to get, um, “interesting”. Note that this may probably an understatement considering the fun I had while optimizing the website.

Basically, I think this is how permalink for pages works in WordPress :

[ 1 ] A visitor requested a page, in the form of a people (and Google) friendly link.
Example : http://asiablogging.com/links-2-asia/

[ 2 ] Due to WordPress-generated .htaccess file, Apache will translate the permalink into loading index.php and passing along that permalink to it.

[ 3 ] WordPress will lookup that permalink in the rewrite table, and got the real URL.

The rewrite lookup record can be viewed with this SQL command :
select * from wp_options where option_name=’rewrite_rules’;

[ 4 ] The real URL loaded and shown to the visitor.

So far so good.

However, when we’re talking about **thousands** of pages, then things started to become messy.

Last time I checked, the rewrite lookup table (the thing I was talking about in point 3 above) for Mr. King’s website is about 21 MB in size.
And **everytime** he add a new page, that record will be recreated again, from scratch.

WP developers have acknowledged the problem as very serious. This is because the way it works at the moment (WordPress version 2.3.1), this scheme is not scalable / will give poor performance over as little as 1000 pages.
And since it’s within the WordPress’ core, it will require a rather significant overhaul to get this fixed.

Don’t get it wrong, they’re (I think) most happy and flattered that some people are actually trying to make WordPress to work as substitute of a Wiki It’s just that there’s this technical glitch at the moment that will be causing difficulties to many others from following the same path.
So last time I checked, they’re very interested to get this fixed.

Back to Mr.King - I have now optimized the server so it performs much faster, despite the bottleneck I described above.
There’s still slowdown noticable when creating a new page, but it’s now quite bearable

Anyway, again that was fun indeed. I guess this is why I chose IT as my career path back there years ago - it was fun (and very useful to many people), and it still is today.
Enjoy !

update:
His server had problems and crashing his website. Mr King said that the datacenter guys are looking into it, but I’m welcome to look around as well.

Soon it’s pretty clear that the hard drive of the server is dying. I told Mr King to relay that to the techies, which responded with “how did you figure it out ?” (dmesg + google - duh).

Long story cut short - they botched big time, but thankfully I managed to snatch a backup of Mr King’s website before it went down the flames.
Now I host Mr King’s website on my server, and he’s a very happy guy again.

This entry was posted on Monday, January 14th, 2008 at 13:12 and is filed under Teknoblogia. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.