Perrin Harkins wrote:
> > Yes, exactly. My plan is to have a table with the tasks in my database,
> > and check expired tasks in a cleanup handler. I'll have to lock the
> > table, so that only one process does that. I'll also query the database
> > only every so often, not at every request cleanup.
>
> Well, by frequently hitting your web server and having it look in the
> database to decide to do nothing, you're putting a lot of unnecessary stress
> on your server. What's wrong with making individual cron jobs that call
> individual URLs (think of it as RPC) to cause actions on your web server
> exactly when you want them done? Doesn't that sound a whole lot simpler?
I think you are over-evalutating the stress on my server. With the
speediest time base I was talking about (once per minute cron job), that
would be 1440 HEAD requests per day, each requiring 1 simple database
query that will most probably return no row at all (a query that returns
many rows is slower, because it has to transmit these rows).
Many sites with database-driven pages have multiple complex queries on
some pages and run in the millions of page-views per day.
As for the simplicity, having multiple individual custom cron jobs is
simpler than one single generic cron job?
But still, I don't like my solution very much either. My problem lies in
the case where I get a lot of hits, I want to be careful of what I run
in my cleanup handler (if I hit the database at every cleanup, I'll
start piling up daemons if I get plenty of hits). I was thinking of
having a variable with a timestamp of when we last checked the database,
and getting into a cleanup handler, we'd hit the database only if it was
more than a minute ago that we checked.
--
Implementation: n., the fruitless struggle by the talented and underpaid
to fulfill promises made by the rich and ignorant.
