Ticket #175 (closed defect: wontfix)
Unmanaged Files slow down as More Files get Added
|Reported by:||cgountanis||Owned by:|
|Severity:||major||Keywords:||fdo,mapguide 1.2 beta 2, shp, dbf|
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? Was testing on Windows 2000, XP and Vista with same results using MGOS 1.2 B2 and FDO 3.2.2 B2.
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>
Easy way to reproduce this would be create an unmanaged shp feature source. Put one shp file with associated files and create a map. Goto the web layout stage and make sure you test with something that queries feature sources like zooms. Now add 20+ shp files the bigger the fdo the slower it gets. Don't change the map or web layout. Do the same thing as before run the site with the initial one layer and zoom. You should notice a HUGE slow down compared to the single shp file as started off.