[mapguide-internals] RFC60 finalization

[Traian Stanev]

I agree. "Could be", "a lot" and "significantly" mean nothing. If you said something like "25% of request time for my map is spent parsing symbol definitions", then we can talk about fixing it. Profilers do exist. 

Traian

________________________________________
From: mapguide-internals-bounces at lists.osgeo.org [mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Walt Welton-Lair [walt.welton-lair at autodesk.com]
Sent: Monday, October 26, 2009 7:09 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 finalization

> Empirically we only know so far that 4 times a small tile takes A LOT
> longer than a tile 4 times bigger .....

And that has nothing to do with having one instance of SEMgSymbolManager per thread, which was your original concern.

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
Sent: Monday, October 26, 2009 6:27 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] RFC60 finalization

inline...
Traian Stanev wrote:
> It's implementing the simplest effective way of caching -- generally you have lots of features sharing the same style within a request and it will only parse the style once for those features. Having a global cache is more complicated because it also has to monitor changes to symbol resources -- and it would have been even more annoying to implement back when we theoretically allowed for the resource service to run on a separate machine than the mapping service.
>
... has the plan to move the resource service to another node been
abandonded?
If so this opens the route to more efficient use of the internal map
structures ....

How big is the share of TileRequests in the general picture?
Maybe this is a good time to ask people for their usage patterns to
collect some statistical usage data....

However, parallel tile requests to the same scalerange of the same map
seem like a very popular use case ...
... and they are all sharing identical featuretypestyle data
thus I see a lot of potential to streamline the map cache structures by
tying it more closely to the map data.

In the context of RFC60 the reuse of the symbolcache for the colorsearch
requires some code changes due to the current scoping of the symbolcache.
A singleton based shared mapobject providing cache structures tied to
the maps lifecycle could be a much more performant approach here.
Sharing mapdata across http requests this way could significantly
improve server performance.

Any thoughts??
> Do you have any empirical results of a real world map showing that the current implementation results in a high relative overhead of symbol parsing compared to, say, FDO requests, or PNG saving or the symbol stylization itself?
Empirically we only know so far that 4 times a small tile takes A LOT
longer than a tile 4 times bigger .....
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals