> > When your traffic gets twitteresque, please call back. Operators are > standing by. > > /* see also "premature optimization" */ :-)
There is no so such thing as premature optimization, maybe mis- prioritized optimization (may be more impactful things to address first), but if you wait until you "have to" optimize to do it...it is too late. Especially is you cansider tha optimization may require rethinking table structure and/or other fundamental architecture. There is however a such thing as a premature jerky, smart ass response like the one above.. That said, a couple of questions first: - How is your query structured now? find(:all, ?????)? - What restrictions do you have on the reminder period if any? Can they chose any time of the day, any frequency? Or is it restricted ot "every 15 minutes", "every hour" etc? - How many users do you have now? How many do you expect need to scale too? - How long are the queries taking now? too long? This are questions that you should answer/aks when making a decision on the need and approach for optimization. For instance restricting the notification times/intervals to a few fixed values lends itself to multiple improvements, at a cahcing/queing level, as well as at an SQL query level. A few VERY general ideas on how to approach this are: 1) SQL optimization, use direct SQL connections and optimize the query as appropriate for your DB type using constructs such as SORT, GROUP BY, creating indexes,etc. 2) Do the sort/search in "object space" using a partitioning approach. 3) Fake a crude "bucketing" system using additional look-up tables, or more specifically has_many relationships to parition based on fixed intervals. for example an hours_of_day model that has_many_and belongs_to_many :reminders, with one row for each of the 24 hours of the day. You could then relate each reminder to on one of the rows. Your background process then ask for all records that are associated with the row representing the current time....convoluted I know. The performance banifit may be questionable because of the JOINs required for a habtm look-up, but it should be less brute force then a find all. I have quite a few others ideas, but will leave it at this.... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
