[OpenLayers-Dev] Performance question

[Christopher Schmidt]

On Sat, Jul 28, 2007 at 02:29:13PM +0100, Ludwig M Brinckmann wrote:
> >
> >
> > In general, I would advise against having 11 seperate layers on a map.
> > It's possible that this really is neccesary, but in general, 11 layers
> > is more likely to confuse the user: You're the map maker, make some
> > decisions about how the map should look, and combine some of the layers.
> 
> 
> Well, I think there are many situations where one would want to give a user,
> which might not be the general public, a _lot_ of layers and I would argue
> that OL should should support this.

The primary issues with supporting this are not issues that can be
solved on the client side. 

Take 10 layers as an example, and a map viewport of 1000x800 pixels.
This results in a 4 x 4 tile viewport. Buffer around that of 2 in each
direction -- 6 x 6. 6 x 6 * 10 -> 360 tiles. 360 tiles at 30k apiece:
10.8MB of data. 10.8MB of data over 512kbps connection: 172s, plus .1s
latency per tile, divided by two (the number of connections a browser will open
to the server at once) 36s / 2 -> 18s. 

So, if you want to load 10 layers in a typical map setup, you're dealing
with 190s of load time, *assuming that tile generation is instant*.
Since we all know that with the exception of TileCache, tile generation
isn't instant, we need to take that into account: even assuming that
each tile only takes .5s to load (a pretty conservative estimate, given
the state of many WMS servers on the web), the data takes an additional
90s (360 * .5, divided by the same 2 above, 360 / 2 / 2 -> 90). 280s to
load data, and that's not a particularly good case: even with a *single*
layer I've occasionally seen cases where loading data takes up to 30s,
much less in the massively layered case. 

Now, I understand that there are a number of optimizations that can be
done, but in general, there are limitations of working in the browser
that make loading many tiled layers from the same server unrealistic in
the browser environment.

That said, I'm not claiming that OpenLayers should abandon this use
case: the response I made was only in response to the question from the
original poster, who was being afflicted by slow load times. There's
only so much that can be done on the clientside for that. As far as user
interface for management of layers, I admit that OpenLayers is lacking,
and there are people working to improve that -- Lorenzo Becchi's WMS
Manager code is an example of that -- and if there were to be an effort
put together to manage layers better on the client side as far as visual
interface goes, I'd be behind it. There have, in fact, been several
efforts by various users and developers, but in general, they are rather
limited in how much they provide, and what they expect -- not 'general'
enough, in my opinion -- and have not been developed to the neccesary
extent for inclusion in trunk. 

> I have found that with mapserver vector layers it is often better to just
> have a single tile as the effort creating the tile lies in the DB or
> shapefile access and because Mapserver will, depending on setting, either
> discard elements at the edges of tiles (which would be in the middle of an
> OL tiled window), or the symbols do not line up well or a duplicated on more
> than one tile.

For the record, this is exactly the kind of thing which TileCache, with
meta tiles, or ka-Map, are meant to solve.

Regards,
-- 
Christopher Schmidt
MetaCarta