See the queue

GavinX · 2011-01-08T06:07:27.000Z

I requested a map several days ago but notice alarmingly the queue is getting longer!

Is there any way to see the queue of maps waiting to be built without actually requesting a map?

Thanks for the incredible service by the way.

Gavin

Lambertus · 2011-01-08T08:32:18.000Z

I’ve noticed it too. But unfortunately there is very little I can do. The server is working full stop 24/7. It’s just that somehow, since Christmas, there are many more requests then usual.

I did fix something yesterday that was causing some trouble: the requests in the queue were processed at random and with so many requests it happened that very old requests were never processed. So I changed the processing script to sort the requests at file creation date.

GavinX · 2011-01-08T14:07:47.000Z

Should I re submit the map request?

Andy_Frigaard · 2011-01-12T04:57:49.000Z

Hi Lambertus,

Some ideas to help you manage the load (or manage the users behaviour!) …

In the past when there was less load, I think it set an expectation that the job will always run within a few hours. I guess that some people may be submitting multiple requests in the queue. I did this, as I had no reply to the first one after about a day, so guessed that there was some issue.

Perhaps you could add a check to delete any previous requests for the same email address? This might help to remove any multiple requests in the queue.

Also it would help to indicate the expected processing speed of the queue - I got a message stating that there were 450 jobs, but most people would not know if this took 1 hour or 100 hours to complete. Maybe add a line to the message like "about 20 jobs are processed each depending on job size etc…).

If the queue size was visible on the main map screen it might encourage users to download a cached tile only. Sometimes we download data just because we made a recent update, and want to see it on the GPS. Or it is Friday night, and we want an update for a weekend trip. If we know that the delay is 2 days, some people may not place a request.

Thanks for this service - it is invaluable, and is one of the reasons I bought a Garmin!

Andy

Lambertus · 2011-01-12T10:16:29.000Z

GavinX:

Should I re submit the map request?

No, you will receive your email when the processing of your request is done. You won’t speed things up by requesting again as the queue is a FIFO (but it won’t slow it down either, see below).

Andy Frigaard:

Some ideas to help you manage the load (or manage the users behaviour!) …

Thanks for your input, it’s appreciated!

In the past when there was less load, I think it set an expectation that the job will always run within a few hours.

No, the server does not render maps in anticipation of a request. It’s a reactive process, not proactive.

I guess that some people may be submitting multiple requests in the queue. I did this, as I had no reply to the first one after about a day, so guessed that there was some issue.

This is what I see happening often but it’s not a problem. If you request the same map twice then the second request will be handled by the caching mechanism which just sends you an email and nothing more. So a duplicate request makes the queue look longer but doesn’t have effect on the delay between the time a user submits his request and the time he receives the email.

The only time a duplicate request can be a problem is when the queue delay is longer then the cache timeout and the user requests the same map twice: one at time X and one at time at approximately (X + cache delay - queue_length). In this situation the first request has just been deleted so that the second request has to be rendered again, instead of just sending an email. But I expect this to be a very rare occasion and therefore can be dismissed.

Perhaps you could add a check to delete any previous requests for the same email address? This might help to remove any multiple requests in the queue.

See the previous answer. It’s not really a problem.

Also it would help to indicate the expected processing speed of the queue - I got a message stating that there were 450 jobs, but most people would not know if this took 1 hour or 100 hours to complete. Maybe add a line to the message like "about 20 jobs are processed each depending on job size etc…).

Yes, good idea. My very crude calculations indicate that it takes -on average- about 5 to 10 minutes per request. I can add this to the confirmation page.

If the queue size was visible on the main map screen it might encourage users to download a cached tile only. Sometimes we download data just because we made a recent update, and want to see it on the GPS. Or it is Friday night, and we want an update for a weekend trip. If we know that the delay is 2 days, some people may not place a request.

Again, a good point. Although a bit more difficult to implement (because the main webpage is on another server).

Thanks for this service - it is invaluable, and is one of the reasons I bought a Garmin!

Thanks. I guess Garmin owes me a beefy server!