On 2010-08-30 16:48, Danilo Šegan wrote:
Say... I think we should do that, but until then, what about this
short-term fix?
When I say "optimized" for a trigger, I usually mean "removed" :)
That's what I understood, and that is what I meant. But this is a
suggestion for a short-term fix until we get to that point. Something
we could do even this cycle, before those 100,000 or so OpenOffice.org
files currently awaiting review hit us.
I think it would be just as simple to recalculate all the translators
along with a statistics update. And "pofile.updateTranslators" call
should be separate anyway (so we could do it in the same manner we do
updateStatistics today: once per web page submission, or once per
import).
That means that the cron job has to run before users see their changes
show up on their personal pages. That could be painful. I'm sure with
some work we can cut the delay down from the current 1 or 2 days to
"less than an hour" but even then, it's a shame to let go of interactive
response times.
OTOH, if we could make the change after we introduce message queues, we
could take the computation offline yet still get interactive speeds.
But in that case we'd want an interim measure to take the write pressure
off POFileTranslator.
Jeroen
_______________________________________________
Mailing list: https://launchpad.net/~launchpad-dev
Post to : [email protected]
Unsubscribe : https://launchpad.net/~launchpad-dev
More help : https://help.launchpad.net/ListHelp
