Comments on: Re: Simple RoR+MySQL optimization

By: Chris Heald

Chris Heald — Wed, 01 Oct 2008 16:33:04 +0000

JGeiger:

Here's what I came up with. Not too surprising. :)


[chris@polaris benchmark]$ script/runner benchmark.rb
find_by_sql (10000x)
  2.430000   0.580000   3.010000 (  4.457347)
find_by_id (10000x)
  4.520000   0.490000   5.010000 (  6.620790)
find with conditions (10000x)
  3.740000   0.530000   4.270000 (  5.881615)

By: JGeiger

JGeiger — Wed, 01 Oct 2008 08:54:59 +0000

I was wondering about what the difference would be for #1 if you replaced User.find_by_sql "select * from users where id = 123" or User.find_by_id 123 with

User.find(:all, :conditions => ["id = ?", 123])

It would seem that the find_by_id adds missing_method overhead, while the find(:all) should bypass that, and give you something a bit more similar to the find_by_sql.

Thanks.

By: Chris Heald

Chris Heald — Wed, 01 Oct 2008 00:04:09 +0000

Doh! Stupid me on the quote labels there. I’ve corrected it – thanks. :)

These were run against my development box, though, which does have the MySQL query cache turned off so I can more easily track down errant queries and the like.

By: Ken Miller

Ken Miller — Tue, 30 Sep 2008 18:22:08 +0000

OK, that's better. :) Thanks for the benchmarks…

By: Chris Heald

Chris Heald — Tue, 30 Sep 2008 18:20:40 +0000

Generated a table with 5,000,000 rows, consisting of an id field and a value field; id field is a primary key, type INT.

The benchmarking script (with corrected labels!) then produces the following:

Run #1:

Without quotes (10000x):
  0.090000   0.210000   0.300000 (  0.929264)
With quotes (10000x):
  0.120000   0.220000   0.340000 (  0.916973)

Run #2:

Without quotes (10000x):
  0.120000   0.140000   0.260000 (  0.903709)
With quotes (10000x):
  0.140000   0.170000   0.310000 (  0.951744)

The zip code thing makes perfect sense, though – I absolutely agree that when you're querying against a string column type, make sure that you're passing a string! The example the original author had, though, was passing an ID in a query as as a string, which observationally just doesn't decrease performance to any significant degree.

By: Ken Miller

Ken Miller — Tue, 30 Sep 2008 18:16:06 +0000

Well, the more I think about it, the more I'm on crack wrt the performance implications of passing strings into int columns. But the other way around is definitely true, even though the query will work just fine. We saw this with zipcodes: to tell if SELECT * FROM zipcodes WHERE code = 500 will match a row with code = '00500' it has to actually convert the string, according to its match semantics.

By: Ken Miller

Ken Miller — Tue, 30 Sep 2008 18:13:04 +0000

Actually, I should caveat that. Passing strings to ints isn't as bad as passing ints to strings, depending on how MySQL is set up. But we've definitely been bitten many many times by weird, difficult-to-reproduce bugs when passing strings as ids.

By: Chris Heald

Chris Heald — Tue, 30 Sep 2008 18:10:42 +0000

That's an interesting observation; I would have expected the database to perform a cast of the passed value to the expected data type of the field before passing it to the index. I've been doing development against SQL databases for nearly a decade, and have never run into that one.

I'll generate and run some tests against some tables. Is there a good reason that the database wouldn't cast the value to the column's data type?

By: Ken Miller

Ken Miller — Tue, 30 Sep 2008 18:08:06 +0000

One more comment: the quotes/non-quotes issue is VERY real, and works both ways, strings as ints, and ints as strings. But to really see it, you need to be working on a largish table with an index on the column in question, because what's going on is that when you pass the wrong type of data, it screws with the index utilization. If you pass a string to an indexed int column, rather than convert the value you passed to an int, it converts EVERY VALUE IN THAT COLUMN to a string, which triggers a table scan.

There are also subtle bugs that come in, such as 64-bit overflow when converting strings on 32-bit hardware, etc. In any case, it's just a good idea to have your data types matching.

By: Ken Miller

Ken Miller — Tue, 30 Sep 2008 18:02:07 +0000

Hi there,

In the quotes vs. non-quotes your experimental setup is exactly wrong. You print "without quotes" next to the one that has quotes and vice versa. :) Also, unless you've specifically disabled it, you're likely running all your queries out of MySQL's query cache. To disable, put /* SQL_NO_CACHE */ somewhere in the query (after restarting your db to clear any existing cache) or just set system variable query_cache_type to OFF.