maposmatic-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Maposmatic-dev] [task #10050] Improve Estimated Rendering time


From: Jeroen van Rijn
Subject: Re: [Maposmatic-dev] [task #10050] Improve Estimated Rendering time
Date: Wed, 6 Jan 2010 16:44:14 +0100

On Wed, Jan 6, 2010 at 16:12, David Mentré <address@hidden> wrote:
>
> Details:
>
> A simple algorithm:
>  1. compute average rendering time over the last 10 jobs, e.g. 7 min
>  2. for each job in the waiting queue, multiply its position by the previous
> rendering time, e.g. jobs in position 100 is estimated at 100 * 7 min = 700
> min
>
> Possible issue:
>  * When do we compute and/or refresh this? For each row it might make to many
> DB requests

Have the daemon time itself and increment a
total-rendering-time-in-minutes variable as well as
total-jobs-rendered stored in the database (or a simple .py include
referenced by the Django frontend). The average time per job will then
automatically converge. Of course I can see the benefit of having a
moving average with a 10-job window as you proposed, it would converge
more quickly if the hardware or software is updated and jobs start to
run much quicker/slower than before. It could also just store those 10
jobs, their length, and an additional precomputed average so the
frontend doesn't need to recalculate this.

Same solution, really, except you could use a simple list of tuples
[job number, job length in minutes]. Strip off the first entry, append
the newest entry. Then pickle to the database or Django include.
Either way there needs to be only a single query added on displaying
the waiting time, and it would only get queried and used for
computation if someone looks at the status of their pending job. No
need to compute this for all pending jobs.

Bonus: On the front page show the average waiting time for any job
you'd submit right then. This would be the average time per job as
before, multiplied by the number of outstanding jobs. Again something
that the daemon could easily calculate and store in a .py file
somewhere at the end of a job.

Also, on implementing this, don't forget
https://savannah.nongnu.org/task/?9998 (task #9998: Allow multiple
instances of maposmaticd (multi-processor machines) in case you decide
to have the daemon precalculate these stats.

I hope I'm making sense here. ;)

n.b. Is there a difference between address@hidden and
"MapsOSMatic Dev List" <address@hidden>, or does one
forward to the other?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]