Optimization for the expireover procedure.
rra at stanford.edu
Wed Oct 17 00:21:46 UTC 2007
Bill Davidsen <davidsen at tmr.com> writes:
> But the most desirable change would be to spread the expire load over
> all uptime, so that the server avoids a load spike when expire runs. To
> that end the ability to set expire time at the moment the article
> arrives is a benefit, and frankly most sites don't change their policy
> all that often, and even if a recalculation of all the expire times were
> needed when the policy changed, it would still probably be a win.
Bill, your problems are with the history expiration, not the overview, and
none of this will actually help with that. For that, we need a history
database format that supports random-access deletes without making the
normal history write and check performance too slow, and while I came up
with a few ideas, I never had time to implement or benchmark any of them.
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
More information about the inn-workers