This is true, in fact I think the only slightly complicated bit would be maintaining concurrency between the scheduler in memory and the tasks in the table. You don't want to be querying a database every second (although that would work around a particular MySQLdb bug people have mentioned), however in a clustered environment you can assume that tasks will be added to a table by another process on occasion - a process which is unable to notify the server that is running scheduled tasks that the task list has changed (within reason).
On the other hand.. is querying a database every second so bad? I wonder how people would react to a "select list, of, fields from table where date <= now())" every second. A production application should be processing at least a page request a second, which is usually a lot more than one query. Our primary combi-webserver at work handles about 5 requests for pages a second, almost all of them requiring more than one query, without breaking a sweat. FYI MySQL's runtime info is currently reporting an avg. of 74.64 QPS over 10 days (extended power cut :-( ), + serving pages & DNS, and CPU hovers between 5% and 15%, load average: 0.22, 0.19, 0.14. It's an XP3000 with a gig of memory. Our dedicated database processes a few hundred QPS on a Dell Poweredge 1850. So actually on second thoughts I wouldn't be too upset with 1 query per second. But if people are concerned perhaps we could get all the tasks for the next minute at once and store them in-memory? -Rob Jorge Godoy wrote: > Em Terça 16 Maio 2006 19:40, Jorge Vargas escreveu: >> database? why does cron depends on a db? > > In this case, for persistence of information. But I believe that this should > not be a dependency but some kind of extra feature. I also believe that > putting these scheduled events inside a database isn't hard. > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears -~----------~----~----~----~------~----~------~--~---
