Indeed, Mapserver is definitely using my index. I confirmed by deleting
it, and re-testing.
The problem scenario really stands out with big data sets. My test data
set has 4 million polygons, so probably too large to attach to a bug
report. I'll see if I can find a smaller data set that exposes the problem.
I'll also try to dig up the Geoserver code which handles the index scan.
I'm going to wait on creating that ticket until I've got more info...
Brock
Daniel Morissette wrote:
Brock Anderson wrote:
I then make a simple WMS request to fetch exactly 1000 features
(limited by a bbox) from the layer. Mapserver take about 500ms.
Seems a bit high.
Geoserver can draw the exact same data, using the *same .qix* index
in about 150ms. Naturally I made every effort to keep the comparison
fair. No reprojection in either case, nearly identical styling, etc.
Ouch! That's no good. Have you verified that MapServer indeed finds
the .qix and uses it (perhaps by removing the file and seeing that it
then takes several seconds to render the map)?
As a further comparison I noticed that Mapserver and Geoserver are
nearly equal for fetching/drawing 1000 features from a smaller data
set of just 10,000. Response time there is more like 120ms.
So on large shapefile data sets Geoserver's index scanning seems to
be substantially faster. Are there any map file options that might
improve performance? Could it be that Geoserver simply has a faster
implementation for traversing the quadtree?
Could be. In which case we should compare the two implementations to
figure what GeoServer does better, and fix MapServer.
Could you please file a ticket about this with the info that was in
your email? Are you able to share the dataset that you use to
reproduce this? Also, if you can include a link to the GeoServer
source file(s) that handles the .qix reading in the ticket so that we
know where to look to compare the two implementations then that would
be great. I will not have time to look at this before 5.0 is released,
but maybe someone else will... or at a minimum we need to make sure we
try to address this in 5.2.
Thanks
Daniel
