Consider a low-loaded tile server.

The actions of the users might be to:

  • pan around
  • zoom in at the current map position

One idea might be to put the tiles in the queue that are next to the current meta tile (8 pieces - but this case might be already covered by the meta-tile technique) and the meta tile in the next zoom level at the current map position.

What is the starting point to implement such kind of pre-rendering in Tirex?

asked 04 Nov '12, 20:38

AddisMap_Alexander's gravatar image

AddisMap_Ale...
950283755
accept rate: 0%

edited 04 Nov '12, 20:38


You can not implement this in Tirex alone, because requests to existing tiles are handled by mod-tile and never reach Tirex. So you would have to change mod_tile. You could probably change mod-tile to send low priority rendering requests for the next zoom level in addition to the high priority request for the current zoom level.

But I think this is a bad idea. Chances are you'll do more harm than good. A typical scenario is this: User looks at zoom level n, your setup will calculate tiles for same position at n+1. User pans over a bit and zooms in. All renderers are now blocked with rendering what was requested before and can't render what the user actually wants to look at. Tirex promotes low-priority jobs if a high-priority job for the same tile comes in and it can reserve renderers for high-priority jobs, so maybe it can actually work. But there would still be contention for CPU, database access etc. so I don't believe it would be worth it.

permanent link

answered 05 Nov '12, 07:57

Jochen%20Topf's gravatar image

Jochen Topf
4.4k54564
accept rate: 34%

edited 05 Nov '12, 13:25

Concerning the scenario: When the user zooms in, I was hoping that this new high-prio renderings are rendered before the queued low-prior renderings.

(05 Nov '12, 08:24) Alex_AddisMap

Yes, if they are only queued. But if they have already started rendering, they keep rendering till they are finished. And your scenario only makes sense if they often start rendering immediately. If they end up sitting in the queue for a long time anyway, why bother with your scheme?

(05 Nov '12, 08:55) Jochen Topf

It could work, but it'd need more smarts :

  • Only schedule if a worker is otherwise idle.
  • Ability to promote the job from low priority to high.

Maybe could be implemented with a low-priority, low-TTL queue ? Remove job from the low queue if it is added in the high queue. And make sure that you have a lot of workers. Not such a low-haging-fruit improvement, but worth experimenting with.

(05 Nov '12, 11:01) Vincent de P... ♦

I updated my answer based on the comment from Vincent de Phily, because Tirex can actually do the things he requests.

(05 Nov '12, 13:26) Jochen Topf
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×389
×161
×14

question asked: 04 Nov '12, 20:38

question was seen: 2,431 times

last updated: 05 Nov '12, 13:26

powered by OSQA