How to Avoid Hanging Yourself with Rails
The law of unintended consequences. Evidently people are searching on figuring out how to leave this earth in Google and getting to this page because of the title with alarming regularity. If you’re one of these people PLEASE see a psychiatrist, talk to someone you love, take a deep breath, realise that you’ve got your whole life ahead of you, whatever it takes.
This evening I presented at the monthly TSOT Toronto Rails Project Nite. As promised here’s the presentation and links to resources mentioned. Big thanks to TSOT, everyone who came, everyone else who presented and the spirit in the T. Ruby/Rails community.
Presentation - How to Avoid Hanging Yourself with Rails
Faker - faker.rubyforge.org
‘mrj’s ActiveRecord select/include patch - http://dev.rubyonrails.org/attachment/ticket/7147/init.5.rb
include preloading optimisation - http://blog.codefront.net/2008/01/30/living-on-the-edge-of-rails-5-better-eager-loading-and-more/
Some points following on from this:
- YMMV, times were produced using a consistent dataset, results are going to be all over the place dependent on columns, table size, indexes, ordering etc etc.
- By testing with real (/faked) data, you can avoid (to some degree) the premature optimisation problem, you’ll see what your app is going to perform like closer to a real world production environment.
- Word on the street is Datamapper + Merb is wickedly fast, I’m going to run a test with the same dataset just to see what the difference is like
- There were no MySQL optimisations preformed, just a vanilla MySQL install.
- I’m not being negative on the core team about the select/include problem, it’s a hard problem to fix, I’m just making people aware of it so you can save the banging-of-head-on-desk problem others of us have suffered.
- If the presentation bored you to tears, you know it all already, live in Toronto, and are bored in your job - we may have a position for you. Talk to me…
If you’re in T. make sure you get yourself along to the Rails pub and Rails project nites, well worth it for networking and learning respectively. I hope to see every developer in T. putting forward a presentation on their projects, by collaborating and sharing we all learn immensely. Personally I’ve found every presentation exceedingly interesting - keep it up !
19 Comments, Comment or Ping
Corina
Rowan thank you again for your enthusiasm and support of TSOT’s Ruby on Rails Project Night. I have received a ton of positive feedback about your presentation, and I know our audience really values having this information online for their benefit. We look forward to having you back!
Feb 13th, 2008
admin
You’re welcome Corina - see you next time.
Feb 13th, 2008
Cameron Booth
thanks for this, one of those things that you know needs to be done, but you’re totally right about not making enough time for it when in development. I’m going to check out Faker right away
Oh, btw - I’m not in Toronto any more, but the rest of the team I work with is, they sometimes go to the Rails pub night, but are there other things they’re missing? Rails Project night?
Cheers!
Feb 24th, 2008
admin
Cameron - yes it’s the TSOT project nights, look for announcements in the Torror google group http://groups.google.com/group/torror
Feb 24th, 2008
E. James O'Kelly
And this is why I roll my eyes when otherwise smart guys tell me not to use find_by_sql, or complicated :selects and :includes in my ruby code.
It isn’t about pre-optimization either, it is a simple fact that there will eventually be a shit load of rows in our database. No one builds an application with the idea that it wont be successful.
So take the time (not much at all) to STOP doing Object.find(:all) and leaving it at that. Do some scoping, do some selecting, do some optimizing and your client will be happy not to have to call you 3 months down to the road to tell you they are throwing away what you wrote because it doesn’t scale.
Good writeup.
Feb 25th, 2008
Neil
Thanks for the pdf, Rowan, it’s a great presentation! Probably the first time I’ve downloaded a pdf and managed to read through the whole thing without skipping to something else in between! Skillz!
Seeing as hard-coding SQL is so much faster, do you jump straight to putting find_by_sql in the models when in development? Or do you just reserve it for production?
I’ve only just started with Rails, but I’m seriously tempted to give Merb a spin now…
Feb 25th, 2008
admin
wow all this feedback !! I might have to write more.
Neil - it all depends on the application, as I put in the slides, if you are building the next facebook killer, and you know you’re going to have some page that is going to hit umpteen req/s, you start looking at find_by_sql().
I generally make sure I’m including where it makes sense from day 1, then start looking at selects and find_by_sql on a case by case basis.
It’s all how long is a piece of string - if you’re building a business app which has low page throughput rates, then maybe just :includes are good enough, but as the page throughput rates go up and response times become important more weight is put on optimising queries. Or, if you’ve got a table which has blob data on it, you’re always going to be using :select when accessing it.
Basically watch the output of your development log, if you’re seeing screeds of slow sql queries on commonly used pages, you know you’ve got an issue…
Feb 25th, 2008
Will
Definitely one of the most helpful posts/presentations I’ve read in a while. Thanks.
Mar 9th, 2008
Reply to “How to Avoid Hanging Yourself with Rails”