[MapProxy] mapproxy and fastest option of serving huge imagery on web map on the fly

[Oliver Tonnhofer]

On 21.05.2010, at 21:47, karsten vennemann wrote:
> [...] However did
> I understand this right ? Mapproxy can have TileCache or other TMS input and
> output that as a regular WMS ? That would be incredible because that would
> allow TMS to be input into non WMS-C and TMS capable viewers such as
> MapBender ... which I was wanting to do for a long time..

Yes, that's possible if you already have a TMS. But you can also use MapProxy as a TMS _and_ WMS using the same cached data and the same WMS sources.

I'am currently updating the documentation for the next release and I will upload a new version to http://mapproxy.org/docs/ in the next days. Until then you can find the raw documentation at http://bitbucket.org/olt/mapproxy/src/tip/doc/
in configuration.rst you will find a small section named cache_tiles.

> Another question - does mapproxy always store the physical tiles on disk or
> only the requests? E.g. if I would use a TileCache layer (seeded on disk)
> and then use it as WMS through mapproxy - would mapproxy create another
> "stitched together" tile set on disk ?

It does store tiles on disk. It is pretty similar to TileCache in this regard. It requests meta-tiles, splits them into smaller tiles (256x256, but that's configurable) and stores these tiles on disk. WMS responses are generated from these tiles (stitched/scaled/transformed). MapProxy only caches images for configured resolutions (levels). Responses between these resolutions will be created from the next best cached level.

>> Do you have some numbers how 'slow' MapServer is with your 
>> images (low and high resolutions)?
> [...]
> So far I got these simple results:
> [...]

Ok, here are some results of the MapProxy.

With cached 256x256 PNG tiles on a MacBook Core2Duo 2.26GHz (single threaded test):

     size       ms  req/s
  500x500   35.653  28.05
1000x1000  112.582   8.88
2000x2000  369.019   2.71

These are results when MapProxy does not need to scale/transform, i.e. your clients have fixed scales.
The performance decreases in when scaling is needed. Depending on the resampling used by MapProxy you will see differences from nearly zero with nearest neighbor up to a third with bicubic.

With 1000x1000 request that requires resampling:

               ms  req/s
nearest   113.195   8.83
bilinear  180.634   5.54
bicubic   364.302   2.74

With the right deployment MapProxy scales nearly linear with more CPU cores. So with a quad core you can expect to handle nearly four times more requests.

Regards,
Oliver

-- 
Oliver Tonnhofer <olt at omniscale.de>
Omniscale - Dominik Helle, Oliver Tonnhofer GbR
Nadorster Str. 60, 26123 Oldenburg
Tel: +49(0)441/9392774-2 (Fax: 9)