Remember the couple of posts I made back in November in the tuning section ? Well, I finally got the time to look into this issue again and have made some interesting discoveries the last couple of days. I'm really enjoying this.

The following table illustrates some comparisons between a stock Base 1.3.9 (ossim patched) and the tuned rewrite I've got running right now. These optimizations are now part of our appliance offering (updates for already deployed ones on the way) and will be released to the public afterwards. Thanks to everybody that has been helping me on this, specially to the people at #ossim in freenode ;-).

I'd like to share my first actual success on mysql tuning, after having spent a couple of days reading everything I could about the matter (and still waiting for the books to arrive).
From what I've seen a very important point on DB optimization is the right table design, followed by the right queries and finally optimizing DB parameters. Since I don't know enough yet about optimal DB design I'll skip that phase (tho I'll definetively accomplish it during the next weeks/months) and examining some queries.

After enabling log_slow_queries, one of the first queries popping out continuously was the following:

SELECT *, inet_ntoa(src_ip) as aux_src_ip, inet_ntoa(dst_ip) as aux_dst_ip FROM event_tmp order by id desc limit 1;

I've finally decided to learn everything I could about MySQL performance tuning; we're working on highly tuned appliances and this is a must for high-traffic environments.
I'd like to share my first findings on interesting stuff and encourage comments on the matter, which seems as deep as any science.

These last days we've discussing about this at the office and we couldn't agree about the type of database configuration using MySQL was optimal for the broadest range of users.
It's much easier to tune everything if you already know the exact environment, available hardware and so on, rather than trying to tune a database for a broad range of people going to install a product.