First of all this is not an easy task. There are two main part to for fill this task: gathering of users that needs to remind and sending the actual reminder.
Depending of your application data structure the selection of users should be done by the used database engine as they are build for that kind of tasks. You should build appropriate SQL statement, optimize indexes for that query and try to gain as much performance of it as possible. Sending the reminders are the different issue and I will probably use set of daemons to perform it. However, there are some additional issues you had to address. Like: - What if for any reason the reminders are not send in appropriate time? Should you ignore that unsend reminder or not. - How would you handle increase number of reminders if your system can not send them in one circle time? How will you detect such situation? - If you use more threads to perform sending the reminder how will they share the same cache of selected users. This is one of interesting problems that arise from a seams to be easy new feature like sending the reminder to the user. If we have more information perhaps our observations could be more concrete. On Oct 21, 8:46 pm, hemant <[EMAIL PROTECTED]> wrote: > On Tue, Oct 21, 2008 at 8:36 PM, Bharat <[EMAIL PROTECTED]> wrote: > > > Jeff, > > A few pointers since I am maintaining and enhancing a rather large > > application with similar functionality. It seems to work well (most > > of the times): > > > I am firing an SQL query every minute to check for reminders instead > > of 15 minutes so the actual query is not an issue. Its construction > > is: you may want to create a separate table called "reminders" (or > > something similar) which stores reminders records for only those users > > who want them. That way if majority of your users do not use this > > functionality, you are not incurring an unnecessary overhead. This > > table will have an id as every rails table does and will have an index > > on id. It should also have the foreign keys, at least for the users > > (user_id), make sure that it is indexed as well since you will be > > joining reminders and users table based on this foreign key. You can > > have other foreign keys as well, for example, event_id if the > > reminders are for particular events. That is how one to many > > relationship works. You may want to refer to any of the online > > tutorials available on basic database design which is a prerequisite > > to making good rails applications. > > > The scheduling of these recurring tasks is also important. You want > > to use a cron style scheduler that does not load the rails environment > > every time the task is run. If you use the unix/linux cron to > > schedule a rails runner, it will load rails environment everytime you > > call the task which is a very slow and demanding process. My > > application uses Backgroundrb. I am looking for alternatives which > > are simpler, easier to debug, and more reliable. > > Can you file a bug report with a reliable way to reproduce them? I am > sure, we can iron it out. > > > > > The point of all this is that you are not taking on a trivial task, > > rather a substantial one if you want to better architect your > > application so you may want to think through it carefully. Having > > said that, you are thinking of the right things. May be you want to > > experiment with a prototype which is not in your critical path? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
