[Mapserver-dev] Fwd: MapServer testing results

[Paul Ramsey]

Howard,
I am not completely clear on your explanation...
I see you first pull the extent of the layer and do a quick test to see if the
current draw extent intersects the data at all:

  status = SE_layerinfo_get_envelope(sde->layerinfo, &envelope);

Is this guaranteed to be cheap in all cases, at all times? What if I have not
indexed my SDE layer?
Paul



Quoting Howard Butler <hobu at iastate.edu>:

> Paul,
> 
> Is the extent that you are drawing a subset of the entire set of
> layers?  ie, do you have an extent for the map that is set to the entire
> extent of all layers before you draw?  MapServer basically queries the
> extent that is given in the mapfile in SDE.  If you are subsetting, set the
> extent to something smaller first, and then draw your query.  I use a kind
> of multi-tiered query approach to get the responsiveness I want in my
> applications.  First I query for a region (like BC), set my map extent to
> that and then draw.  This is with mapscript of course.
> 
> There is a quite a bit of brute force geometry conversion going on in
> MapServer to convert from SDE geometries. The geometries stored in SDE are
> the same as in shapefiles (I think, not 100% positive on this - Frank might
> have more insight).  Maybe we could look into using shapelib or OGR's
> geometry stuff to do the conversion instead of what exists in
> MapServer.  The memory costs are also high because we are making at least
> one extra copy of all of the points in the geometries to get them in
> MapServer format.
> 
> Then maybe we're copying them again when we project them... :(  I'm
> speculating that ArcIMS hands off the projection duties to the server when
> the projection it is drawing doesn't match the projection of the
> layer.  This saves ArcIMS from having to deal with a full copy of all of
> the geometries and then projecting them all like MapServer does.  I would
> rather poke my eyes out with flaming dung sticks than try to make MapServer
> behave this way though :)
> 
> With current CVS, I've also noticed that the first time connection cost is
> very high, with subsequent costs being very cheap due to the connection
> pooling.  ArcIMS's connection cost profile should be quite similar to
> MapServer, as I would assume that it is doing some connection pooling as
> well.
> 
> There still are some bugs with connection pooling that cause my stuff to
> segfault from time to time.  After I upgraded to SDE 9.0, the strategy that
> I took to prevent them didn't work anymore.  I will be getting back to this
> problem soon, but I don't think it is an issue here.
> 
> The first thing we could do is feed the extent that is given in the request
> to SDE instead of using the one specified in the mapfile.  That will
> prevent SDE from sending back a lot of extra geometries (and attributes if
> you're getting those as well).  I don't know that it does this now...Steve
> might have more insight/comments on this.
> 
> Enough speculation an innuendo for a Saturday night...
> 
> Howard
> 
> 
> 
>