Primate Labs Blog

The redesigned Geekbench Result Browser is online:

While it’s not a major departure from the old design, the new design is much cleaner and fits in with the other Primate Labs websites. Also, the new design lays some important groundwork for some new features and functionality I’m hoping to release later this year.

In anticipation of the upcoming Geekbench 2.1 release I flipped the switch for the newly redesigned Geekbench Result Browser tonight. As part of Geekbench 2.1 a lot of effort has gone into improving the way both Geekbench and the Geekbench Result Browser present benchmark results. I hope you find the new design clearer and easier to understand than the last; I know I do!

The Geekbench Result Browser was down for several hours this morning. I’m not exactly sure what the cause was, but the evidence points to a memory leak (probably in the Browser code itself) that caused Rails to consume all available memory and then fall down go boom.

While the Result Browser is back online and looks like it’s behaving, I haven’t been able to determine what the problem actually is, so there might be more downtime in the near future. If that does happen, let me apologize in advance and assure you that I’m working on the problem.

I spent some time this week adding a feature to the Geekbench Result Browser that I think a lot of you will find useful — performance charts.

Performance charts display the scores (plotted against processor speed) for a certain subset of results in the Geekbench Result Browser (say, all of the results that share a particular processor or motherboard). This makes it easy to compare your computer’s performance against other, similar, computers. If you’re curious about a particular point on the chart, you can click on it and view the complete result details for that point.

Performance charts are accessed by clicking on any one of the “Chart Performance” links you see on individual result pages in the Geekbench Result Browser. Keep in mind that depending on how many results match the criteria of the performance chart it may take a while to load the chart, so please be patient.

Give the new performance charts a try and let me know what you think of them in the Geekbench forum.

I’ve made a few improvements to the Geekbench Result Browser.

I’ve given users the ability to edit the description of their results, as well as add a comment describing their results (for example describing, in more detail, their hardware configuration or cooling setup).

I’ve also improved the search user interface so it’s cleaner, provides more feedback, and can display several pages of results. It’s still a simple text search, so you can’t perform complex searches (like, say, searching for all of the AMD-based systems with at least 512MB of RAM).

Give the new features a try and let me know what you think of them!

Just a quick heads up that I’m moving the Geekbench Result Browser to a new server today. There’ll be some downtime as I migrate the data from the old server to the new server and wait for the DNS servers to update to the new IP address, but hopefully it won’t take long!

Update: Finished! If you’re still seeing the “Server Move in Progress” page, your DNS is out of date and you’re still accessing the old server. Try flushing your DNS cache to get the new server’s IP address.

I’ve added some new functionality to the Geekbench Result Browser; it’s now possible to search for results:

http://browse.geekbench.ca/geekbench2/search

It’s not incredibly clever, but it’s useful enough than if you’re wondering how fast a certain processor is you no longer have to manually search through the result browser until you find one.

I mentioned last week that the Geekbench Result Browser has been rather popular lately; so popular that, for a while, it was having trouble keeping up with the increased traffic. While the server didn’t crash, a lot of the requests were timing out; the requests that didn’t were taking almost a minute to load.

Now, the Geekbench Result Browser is written in Ruby on Rails and is running on a server with only 512MB of RAM; I was concerned that Rails’ memory requirements were starving the database server, causing simple queries to take a third of a second to execute:

Geekbench2Metric Load (0.304654) SELECT * FROM geekbench2_metrics 
WHERE (geekbench2_metrics.geekbench2_document_id = 7275) 
AND (geekbench2_metrics.`metric_id` = 4) 
LIMIT 1

A third of a second isn’t an outrageous amount of time for a query, but when a page makes fifty queries, each of which take about a third of a second, it really begins to add up.

I copied the Geekbench Result Browser database over to my development machine (which has a lot more memory) and started running some tests. Lo and behold the database was still taking a third of a second for simple queries like the one above.

Then it hit me. The problem wasn’t with Rails or a lack of memory. The problem was that MySQL was performing a full table scan when executing simple queries like the one above. Full table scans are fast when the table is small (like it was when I was developing and testing the Result Browser) but get slower as the table gets bigger. No wonder I didn’t notice this during development!

The best way to avoid table scans is by adding an index to the table. I whipped up the following migration to add indexes to the geekbench2_metrics table:

class AddIndexes < ActiveRecord::Migration
  def self.up
    add_index :geekbench2_metrics, 
        [ :geekbench2_document_id, :metric_id ], 
        :unique => true, 
        :name => :idx_document_id_metric_id
  end

  def self.down
    remove_index :geekbench2_metrics, :name => :idx_document_id_metric_id
  end
end

and after applying the migration the simple query got a whole lot faster:

Geekbench2Metric Load (0.000473) SELECT * FROM geekbench2_metrics 
WHERE (geekbench2_metrics.geekbench2_document_id = 7275) 
AND (geekbench2_metrics.`metric_id` = 4) 
LIMIT 1

Hooray! I don’t have to worry about upgrading my server hardware any time soon, and my respect for Rails has increased; hey, maybe it’s not so slow after all! Now, if only databases would index themselves I’d be set.

Both the Primate Labs website and the Geekbench Result Browser have been busy today (thanks in part to the new MacBook Pros). While the Primate Labs website has handled the increased traffic without any problems, the Geekbench Result Browser has had some problems.

As a bit of background, the Geekbench Result Browser is a Ruby on Rails application, and Rails has a reputation for not scaling well. While this hasn’t been a problem in the past (at least not for the Result Browser), it became a problem today when the Result Browser’s traffic in an hour far exceeded the traffic it usually gets in a day. Yipes!

Here’s what the load was like earlier today on the Result Browser’s dedicated server:

[jfpoole@photek ~]$ uptime
17:01:33 up 11 days,  5:11,  1 user,  load average: 13.89, 9.63, 6.24

After disabling a couple of resource-intensive features (like the browse similar feature), the load gradually settled down to something more reasonable:

[jfpoole@photek browse]$ uptime
17:10:58 up 11 days,  5:59,  2 users,  load average: 2.41, 5.70, 8.32

While this is fine for a short-term fix, I’m going to have to make some changes to the Geekbench Result Browser so that it scales a bit better. I’m sure I could fix the problem by buying more server hardware, but I’d like to avoid doing that if at all possible!

You’re now able to view the top Geekbench 2 scores and the bottom Geekbench 2 scores in the Geekbench Result Browser. Right now the top score belongs to an eight-core Xserve, while the bottom score belongs to a PowerBook G3.

While the feature works great, I’m not thrilled with the terminology; can someone suggest something better than top and bottom scores?