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

[Martin Morrison]

For a test, take all of your geometry data and load it to SQL Server 2008.  Make sure your table is populated  with the data from 2005 SQL server.  Note, don't do a join, actually copy the data into the same table as the geom.  Create normal indexes for your search fields.  Create a spatial index for your geom (don't worry about dupes, it doesn't work that way).  Add that data to a new map.  Report back the results.  You will be surprised.  

The only reason you listed that requires Fusion is open layers.

Martin


________________________________________
From: mapguide-users-bounces at lists.osgeo.org [mapguide-users-bounces at lists.osgeo.org] On Behalf Of frosty1_4me [kbowman at cityofgp.com]
Sent: Friday, January 28, 2011 5:02 PM
To: mapguide-users at lists.osgeo.org
Subject: [mapguide-users] RE: MGE performance. It's soooooo     Slllllllooooooowwww

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