[mapguide-users] RE: MGE performance. It's soooooo Slllllllooooooowwww

[Jason Birch]

I've seen huge performance slowdowns with data sources that are storing more
vertices than accuracy requirements would dictate, and have seen performance
improvements with very, very slight linear generalization.

I have also seen performance gains by simplifying complex geometries (such
as curvepolygons or multigeometry) to simple polygons, and making sure that
the data source is reporting this simple geometry correctly.

For Fusion, initial load times can be seriously reduced by compiling a
custom version for use in your map:

http://lists.osgeo.org/pipermail/mapguide-users/2008-August/014002.html

<http://lists.osgeo.org/pipermail/mapguide-users/2008-August/014002.html>Tooltip
responsiveness can be severly affected by having lots of layers that are
selectable or have tooltips assigned (actually, in recent versions this may
only be for tooltips; little fuzzy on this).

Another item that severely affects performance is network speed.  Because
MGOS is sending large-ish rasters instead of vectors, performance is
affected by available upstream bandwidth.  This can easily cause problem if
your organisation's network access is asymmetric; I ran across a situation
once where someone was trying to publish MGOS over a 512kbps uplink.  If you
do the math, this constrains performance even for a single user, and has
catastrophic effects when serving multiple maps at once.

I think our Fusion-based map (http://maps.nanaimo.ca/nanaimomap/) has
reasonable performance, but it isn't quite on the same level as MG 6.5 was.


The only real way around the constraints of a raster-based map is with a
vector-based viewer, built on something like Flash or Silverlight.

Jason

On 28 January 2011 14:02, frosty1_4me <kbowman at cityofgp.com> wrote:

>
> Thanks for the much appreciated responses to this issue.   Here's a little
> more background information as to why we want to use the flexable web
> layouts and not the Ajax viewer.
>
> -  The floating task panes are a very big thing for us especially to
> display
> our reports to our end users.
> -  Thematic layers (queries)
> -  As Gord mentioned the open layers
>
> We are trying to replicate as best we can the enviorment we currently offer
> our MG users, since to remove any that is used so much would be a step back
> not a step forward.
>
> I did go through the 'Mapguide Best Practices' wiki since making this
> initial post and made a few changes that really helped with performance
> after getting the heads up for Gord.
>
> - Setting the cache properly
> - changing png to png8
> - etc.
>
> Those did make a noticable difference.
>
> We also moved all our external datasources (sdf's, raster images) to the
> server that houses the MGE server.  Previously they were on a seperate
> network server, I'm not sure if that actually had something to do with the
> improved performance or not.
>
> -  I'm also going through our datasources we have and importing the data
> into the SDF3 as was suggested so that it limits the amount of data that is
> loaded from the SQL db.  That's not an ideal situation since most users
> have
> been trained to see live dynamic data for any db changes they make, but for
> datasets where having the data update nightly isn't an issue then I'll make
> that adjustment.
>
> I do have a few questions about some of the posts made:
>
> - indexing the geometry, that only works if all the x,y's are unique.  I'm
> not confident that will be possible for all our SQL data.
> - and there is alot of talk about the amount of layers loaded.   Previously
> in 6.5 we could load more data and as such we did.  We have limited how
> much
> is turned on by default, the question I have about the layers and scales is
> I didn't think it would necessary for MGE.
>
> What I mean is, if we have say a parcel layer.  How can that be generalized
> anymore than it is?  So in studio I have a parcel layer that is set to a
> scale of 0 to 20,000.  Introducing more scales against that same data
> resource used to create that layer, would that actual speed it up because
> it's loading the same data set at different scales?  Since the dataset is
> the same, applying multiple scales to it in the styles of MGES should have
> no effect.
>
> -  We have themed layers as well that are very slow.  The themed layers are
> joined layers which hit the SQL db to return the data.   They are extremely
> slow, how are the themed layers being addressed to help with the
> performance?  Themed layers are what makes the GIS powerful.
>
> We currently use:
> IIS ver 6
> MGE 2011
>  -  Map data is sdf, dwf (bbboooo, hiss), and SQL 2005
>  -  raster tiff and ecw
>  -  secondary data from SQL
>  -  using tooltips but using the iframe that accompanies the openlayers
> concept and fusion to load aspx pages instead.  (that is not always fast)
>  -  .Net and VB
>
> Thanks for the info, please keep it coming this is great.
> --
> View this message in context:
> http://osgeo-org.1803224.n2.nabble.com/MGE-performance-It-s-soooooo-Slllllllooooooowwww-tp5970714p5971384.html
> Sent from the MapGuide Users mailing list archive at Nabble.com.
> _______________________________________________
> mapguide-users mailing list
> mapguide-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide-users/attachments/20110128/122f867b/attachment.html