Het is jammer dat er in veel rails boeken vergeten wordt om wat extra aandacht te besteden aan de indexen in je tables. Dat scheelt namelijk een slok op een borrel. En de convention over configuration regel in rails levert op het gebied van indexen namelijk niets op. Geen index. En dat is natuurlijk wel logisch omdat rails niet kan bepalen wat voor jou een belangrijke column gaat worden.
De primary key van je table wordt al automatisch geïndexeerd door in dit voorbeeld MySQL, en dat is in rails de id column. Dus we gaan aan de hand van een simpele demo het verschil aantonen met en zonder index.
We gaan hier verder met wat we opgezet hebben in het → Faker Gem artikel. Ik heb nu echter 25000 records met plausibele data aangemaakt voor deze demo. Verder maken we ook gebruik van de Benchmark module van Ruby. En het gaat er niet om of de tijd exact is maar om het verschil tussen de waarden. OK script/console.
> script/console
Loading development environment (Rails 2.0.2)
>> Werknemer.count
=> 25000
Wat we nu gaan doen is alle werknemers zoeken maar gesorteerd op de column 'staat'. Maar we willen ook weten hoe lang dat ongeveer in beslag neemt. En dat doen we met Benchmark.measure
>> Benchmark.measure { Werknemer.find( :all, :order => 'staat' ) }
# Benchmark @real=1.07471585273743 etc.
We zitten op 1.07 en gaan nu de index toevoegen voor staat. Daarna doen we dezelfde benchmark en zien het verschil.
>> ActiveRecord::Migration.add_index :werknemers, :staat
-- add_index(:werknemers, :staat)
>> Benchmark.measure { Werknemer.find( :all, :order => 'staat' ) }
# Benchmark @real=0.695426940917969 etc.
Dat scheelt nogal wat. Dus check eerst je indexen als je het idee hebt dat je app trager aan het worden is.
Dit is de weblog van Peter Dierx. Gevuld met artikelen en berichten over Ruby on Rails, Mac OS X en hier en daar een Apple nieuwtje.
