[mapguide-users] Unmanaged SHP File Locations

[Andy Morsell]

First, I love the unmanaged resource concept and will most likely deploy
most future MGOS applications this way.
 
But, similar to Chris' problems, I have discovered that displaying tooltips
from unmanaged shape files causes a much more significant performance hit
and delay.  In my case, I have a 150 MB parcel polygon shape file for a
county.  In the unmanaged case, each tooltip AJAX fetch spikes the CPU with
mgserver.exe at 100% for a couple of seconds.  Doing the same with the exact
same shape file in a managed state (not converted to SDF at load time), the
CPU will only hit 25% or less and responds much more quickly.
 
Further, I discovered that the more unmanaged data in a map, the slower the
tooltip response is for all layers.  For instance, if I add another 7 or so
layers (like streets, water bodies, etc) to the map, when I float over a
parcel polygon it can take up to 10 seconds for a tooltip response during
which time mgserver is cranking away.  So, I'm not sure what it's doing at
that point.  All of these additional layers are all in the same unmanaged
data source folder. 
 
I went ahead and loaded all of the shape files into the repository and
created a duplicate map pointing to the new managed feature sources.  This
map behaves fine with tooltip fetches consuming 25% of a single CPU and very
quick response time.  So, this seems to confirm that the more unmanaged
feature sources in a map (at least from the same directory), the larger the
performance hit and the slower the map responds to requests.
 
I have appended this information to the TRAC ticket that Chris started
earlier today.
 
 
Andy Morsell, P.E. 
Spatial Integrators, Inc. 
http://www.SpatialGIS.com 
  _____  

From: mapguide-users-bounces at lists.osgeo.org
[mailto:mapguide-users-bounces at lists.osgeo.org] On Behalf Of Chris Gountanis
Sent: Friday, May 25, 2007 7:52 AM
To: 'MapGuide Users Mail List'
Subject: [mapguide-users] Unmanaged SHP File Locations
Importance: High



Why do unmanaged FeatureSources respond slower as more files get added to
the directory location? We have a FeatureSource called SHPDefualt for
example. The zooms take longer as well as other functions. It seems when you
query a Feature Source is does not hit the DBF you want directly it seems to
fiddle with everything in the unmanaged directory. We love the concept of a
folder that contains all SHP files. One location is great for batch
processes and great for editing new layers. It is just simple for customers
to understand. For sure easier to back up and recreate. Will this always be
a performance killer?

 

 

Is this a bug? Will this be fixed soon?

 

 

This really takes the complication out of knowing what the heck is going on
in the repository. Here is XML Example:

<?xml version="1.0" encoding="utf-8" ?> 

<FeatureSource xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xsi:noNamespaceSchemaLocation="FeatureSource-1.0.0.xsd">

<Provider>OSGeo.SHP</Provider> 

<Parameter>

<Name>DefaultFileLocation</Name> 

<Value>C:\SHPFILES</Value> 

</Parameter>

</FeatureSource>

 

 

 

Chris

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide-users/attachments/20070525/ca3ef124/attachment.html