On Tue, Oct 21, 2008 at 12:55 AM, Jeff Pritchard <[EMAIL PROTECTED]>
> There are up to two per day for each user, but they can be handled > separately. Yes, currently using the disgusting "find(:all)" approach. Since you mentioned using a background task for this, I assumed a straight SQL query. My bad. > 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. My point, which I attempted -- apparently unsuccessfully! -- to make humorously, is that running a single SQL qeuery against a properly indexed database, with even a row count in the millions, is trivial. Really. And if it's being done from a background app, should have little or no effect on your Rails app's performance from the user's perspective anyway. > 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"? Absolutely -- that's what an RDBMS is designed for. > 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. The execution time to retrieve the list and build the queue is trivial compared to the amount of time to actually process the mail queue, particularly as the user count grows. Still, for the sake of argument -- build your "mailing list" in memory, and update it when a change event occurs in the app (user submits a changed profile, new user joins, etc.). Though you'll still incur at least one update/insert into the DB, which is more expensive than a select. One last venom-free comment regarding premature optimization -- if you "fix" something today that /isn't/ broken, you may be making it harder to fix a /real/ bottleneck that crops up tomorrow. Just sayin' ... Best of luck, -- Hassan Schroeder ------------------------ [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
