There are up to two per day for each user, but they can be handled separately. Yes, currently using the disgusting "find(:all)" approach.
No, with just 100 users so far there is no sign of a problem. I just consider the current method to be very inelegant and would rather do it in a more intelligent way. Even if, once we get to a few thousand users, it still isn't causing a "problem", it will be using significant resources, thus reducing the responsiveness of the app. That said, some up-front profiling of the current method might convince me that I'm wasting my time. I'll do that first. Point taken (even if made with more than a touch of venom) So is it generally the case that having the db hunt down the few records we're after each time will execute substantially faster than returning all of the records and doing the comparison "outside the database"? As a novice db guy, the two approaches sound roughly similar, since both cases involve doing essentially the same comparison on the same number of records. Perhaps there is a lot of overhead involved in returning records to the app. I would think that some method of caching the info such that it didn't have to actually go to the db every time would make the biggest difference in execution time. Unfortunately, such a solution would also be more complex than just using a better query. thanks for all the responses. best, jp Bsytlz wrote: >> >> 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.... -- 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 -~----------~----~----~----~------~----~------~--~---
