Hi Marnen, Right now, the max time I'm pulling using the query routines that now have proper indexes and are broken down into manageable pieces runs anywhere from:
18ms - 24ms I don't think that would create a DB meltdown considering these numbers are without caching enabled. I would imagine that once I have caching turned on, the amount of clicks the database receives would be greatly minimized. What I've decided to do (after talking to Slicehost staff) is to prepare for a larger slice upgrade (which would take approx. 30 minutes or less) in the wee hours of the morning if I get hit by too much load. I'm also seriously considering running a cache routine on all matchups each week so that they are cached (this was a pretty good suggestion given). I think given this scenario I should be good to go for now. However, I'm already looking at how to implement the larger table and test it against a double year data load (just for simulation purposes). My problem before was that my tables were not properly indexed and I had two queries that used 13 table joins each. It was just not efficient. The largest join I have now is 7 tables on indexed results. Those queries are only taking 3ms apiece. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
