Karmic Koala – post install notes

No Gravatar

Installed Ubuntu 9.10 a few days ago. Everything seemed OK (very very nice actually) except for a little network performance glitch that may also bother you.√Ǭ† Canonical has once again taken Linux one step further away from the status of geek-challenge to a user friendly alternative to other OS’es.

One thing bothered me though – general network responsiveness seemed seriously degraded. Digging around i found that IPv6 had taken precedence to IPv4 in a few ways – one being DNS lookup sequence. Apparently all lookups was attempted through IPv6 first. My router and network is in no way configured for IPv6 and therefore every connection-attempt to uncached hosts would have to wait for the IPv6 timeout. Two things gave me responsiveness back.

  1. Disable IPv6 at the OS level
  2. Disable IPv6 in Firefox (should give more responsiveness for any OS not running on an IPv6 network)

Maybe you would think that the first step would be enough, but Firefox seems more responsive after step 2. Follow this step to disable IPv6 in Firefox.

Ubuntu 9.10 introduces the GRUB2 bootloader on clean installations only. The upgrade process from, say version 9.04, will not upgrade GRUB and will leave you with the previous version.

To disable IPv6 OS wide, i followed this sequence and voila – responsiveness returned to my netbook (and soon to my other Ubuntu installations).

2009-11-22 update: Had to downgrade to 9.04 again – No matter what I did, which forums I visited – I could not get my Huawei 3G Modem to connect.

Javascript performance on current browsers

No Gravatar

Found this little test which gives an indicator as to Javascript performance in your browser.

On my system (Windows XP on two year old Lenovo T60p laptop) i tried to run it ten times on my browsers with all plugins disabled (lower is better):

Google Chrome: 297,7
Firefox 3.5 beta 4: 340
Firefox 3.0.10: 408,9
Internet Explorer 8: 631,3

As the score is time, lower is better. This is interesing because sites uses Javascript more and more, and as we work more and more online with more applications in the cloud, the Javascript engine has a lot to say about our perception of overall performance.

I got a bit disappointed about my Atom-based netbook – specifically Ubuntu 9.04 on that machine. It never went below 1800 (Firefox 3.0.10) and on the same hardware, the Windows-browsers gives me minimums of 1500 and 2800 for Firefox 3.0.10 and IE8 respectively. Gotta find some tweaks there.

Testing: WP Super Cache

No Gravatar

Seems like a very cool plugin to enhance the userexperience – performance wise, plus it seems to prepare WordPress blogs for high traffic spikes.

Bug found: Links to posts from archives seems to cache PHP-code – not the resulting HTML. There’s gotta be a simple fix. Was a bit quick there. The bug is in my theme – not in WP Super Cache.

Edit: Also – the issues may have to do with my host who seems to mess with their user database right now..

What goes on in my registry when…

No Gravatar

Process Monitor

Ever asked yourself what actually happens when you perform a certain thing in a certain program? Which files are read, created, updated and what goes on in my registry.

The Sysinternals Process Monitor tool does this. Filter the events any way you need and you will be able to release registry updates quickly. I just used it to identify the registry changes performed as I changed the cache settings of IE, so a registry update file can be made and distributed to anyone who needs the same settings. It took about 10 minutes to learn to use Process Monitor and identify the key in question.

MySQL query/indexing tip

No Gravatar

I originally learned about this MySQL shortcoming in the book High Performance MySQL, and luckily I remembered it for an issue that struck me today.

I have two tables – one containing blog-posts, and one containing a record for each tag on these posts. Now the requirement was to show a blog post AND to show the five latest related posts. Related posts in this scenario are other posts that share one or more tags with this post.

Now, it does not take one second to find a blog post, and it does not take one second to find tags related to it. And actually it does not even take a second to find a list of posts having a list of tags. The reason why all these requests take less than a second is because the tables have been supplied with efficient indexes – the table of blogposts has more than 3.5 million records and there are about 700.000 tags.

The problem was that when we tried to generate a list of related posts, the query took up to twelve seconds to run. It sucked and looked like this:

SELECT distinctrow i.id, i.item_title, i.item_url
FROM rss_items_master i
INNER JOIN rss_item_tag t ON i.id=t.item_id
WHERE t.item_tag IN (SELECT item_tag FROM rss_item_tag WHERE item_id=$itemid)
AND t.item_id != $itemid
ORDER BY i.item_date DESC
LIMIT 5;

In plain english we request a list of items that does not match the specific post, but they must have at least one tag that match one of the tags from the specific post. The nested SELECT-statement produce a list of tags to look for, and the outer SELECT statement pulls blog posts containing tags found in the nested SELECT. This does not perform, because only one index can be used per query – so either the index from the rss_item_tag table or from the rss_items_master table is ignored (i did not bother figuring out which one was ignored). To fix it, I split the SQL in two (PHP example):

$sql_tags = "SELECT item_tag FROM rss_item_tag WHERE item_id=$itemid;";
$arr_tags = query_array($sql_tags, $link);
// $tag_o will be an array of tags from the original post.
$tag_o = Array();
foreach($arr_tags as $tag_i) {
array_push($tag_o, mysql_real_escape_string($tag_i[0]));
}
$tags = implode("','", $tag_o);

Now $tags contain a list og tags to look for – actually it contains exactly what the nested SELECT-part did in the slow query. Now these two queries will actually complete in less than a second:

select distinctrow i.id, i.item_title, i.item_url
from rss_items_master i inner join rss_item_tag t on i.id=t.item_id
and t.item_tag in ('$tags')
and t.item_id != $itemid
order by i.item_date desc
limit 5;

So even though the SQL has been split in two, and even though we are passing a lot of information through variables that we have to build from the first query and added quite a lot of code – this outperforms the first single query by a factor larger than 10 – simply because it enables MySQL to use the indexes it should.

For more MySQL performance tips, check out MySQL Performance Blog.