MapGuide RFC 90 - Meta Tiling Support
This page contains an change request (RFC) for the MapGuide Open Source project. More MapGuide RFCs can be found on the RFCs page.
|RFC Template Version||(1.0)|
|Submission Date||(Date/Time submitted)|
|Last Modified||Uv Oct 14 2011|
|Author||Zac Spitzer, Uv|
|RFC Status||(ready for review)|
|Implementation Status||(testing sandbox)|
|Assigned PSC guide(s)||(when determined)|
|Voting History||(vote date)|
Add support internally to the MapGuide Server Engine to map tile requests to larger meta tiles and then slice them up into the standard tile sizes.
With complex maps, it's more efficient to render one large tile than many small ones. In our particular case rendering time for the full map takes up to a week! However, there is little or no benefit for simple maps like the Sheboygan Sample making testing a bit tedious.
Using our 140 layer example map we can observe the following timing using metatile factor 1 & 4 and 3 different locking strategies in the chart below. Unfortunately, the used hardware was not powerful enough to clearly differentiate the effect of the different locking schemes. However, it clearly shows the speedup by using metatiles as such.
Add a meta tile factor to the tile service, which then will render larger tiles enlarged by the provided factor. to be sliced up into the smaller tiles which then get served to clients. e.g.
Client -> GetTile(0,1) -> GetMetaTile(0,0 - 1,1) -> RenderFromMetaTile-> ReturnTile (0,1) -> GetTile(1,1) -> wait................................... ReturnTile (1,1)
Locking the threads to the implicit producer consumer scheme is complex and the file locking seems not very efficient.
The default locking method is 0 which uses a single file per metatile (LockMethod == 0). LockMethod is a config value in the TileService section of the serverconfig.ini together with the UseMetaTiles value specifying the multiplication factor.
In addition an attempt to use ace_conditions has been implemented to get rid of the lockfiles all together and further improve the response time. (LockMethod == 1) There are still some stability issues in the release version.
For example when using a meta tiling factor of 4, 15 tiles will wait while the meta tile is rendered and sliced up. A most efficient locking scheme will have significant effect on this behaviour.
The output of a tile map request has to be identical whether served with meta tiling enabled or without.
There are extra tiles calculated to fill up the grid of the meta tiles. They are empty tile and don't take long to compute. Any algorithm to avoid that would cause a lot of extra complications due to the loss of the currently orthogonal algorithm. This would impact tile generation and locking strategies. Using the MgCooker is adding even more empty tiles around the map boundaries. So we currently think its not an issue.
There seem to be some leaks somewhere which could not be found also with some tools. However, they are small and considering the use case of the metatiling mode - namely filling the tile cache - they might be tolerable.
http://trac.osgeo.org/mapguide/browser/sandbox/rfc90.2 branched from Rev 5924 and merged in changes
so http://trac.osgeo.org/mapguide/browser/sandbox/rfc90 is now OBSOLETE
) - added by 14 years ago.
First test results with metatiling
) - added by 13 years ago.
Sequence for GetTile with Caching
- MapGuideMemoryMetatilingLockfiles.png (18.9 KB ) - added by 12 years ago.
- MapGuideMemoryNoMetatiling.png (16.8 KB ) - added by 12 years ago.
Download all attachments as: .zip