ThinkGeo.com    |     Documentation    |     Premium Support

SQL Server 2008 performance

#1

Good Morning, I've been searching the forums for some posts about improving performance of SQL 2008 layers and I'm not getting too far. Is there a comprehensive post about getting the most out of this feature? Can you give me some pointers?


If I'm using shape files to load my layers, the map loads nearly instantaneously. When I switch over the sql 2008 layers, it takes 57 seconds to load my map. There are 17 layers that I'm changing to be driven from SQL instead. From the point of view of the architecture, it doesn't make sense for me to continue using the shape files. I'm setting the SRID on the layers and I'm using RC1 for my software.


Anything else I should tell you? Any ideas to try?


Thanks!


Kimberly



#2

Kimberly,


Good morning J and thanks for your post!
 
Personally, it is uncommon and unacceptable taking 57 seconds to render a Map using SqlServer2008FeatureSource.
 
About the comprehensive introduction of the MsSql2008FeatureSource, I suggest you read the documentation related with it.
 
I want to make sure 2 things before we get the conclusion that the performance for it is bad:
1) How long it will takes (5 seconds or 20 seconds) to render the map exactly the same, only difference is one using the ShapeFileFeatureLayer, one using the MsSql2008FeatureLayer. And you know that the ShapeFileFeatureLayer will using the RTree as index to speed it up, so I think it is unfair somehow to compare if you do not build index for SqlServer2008 data.
 
2) How is the size of your data in shape file? And can you make some debug information to find out how many features will be rendered in every Map view especially for the view which take 57 seconds?
 
 
Also, three performance improvement solutions are given as following:
 
1) Create the index for your SqlServer2008 data, very similar to other DBs.
gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/21/aft/5529/afv/topic/afpgj/1/Default.aspx#7747
 
2) try to keep the connection open and ONLY close it at the last moment (when you close the app for example).
You know the connection to a MsSql2008 server is somehow time-consuming, especially when you have multiple layers (17 in your case), in every map view, you will open & close multiple times (17 times). So my suggestions is just keep the Sql server connection is alive when you need fetch data always and make sure it is closed before you application is closed.
 
3) Use caching technique.
This technique is used when you have to get all your data back from SqlServer instead of just return the geometry especially when your data consists of too many columns information and you need to fetch all of them or most of them every time.
 
What you can do is you can create your own CachedShapeFileFeaureSource and CahedShapeFileFeatureLayer, and get all the data only at the first time and back it up in memory for later use. Of course, this technique will not be suitable if your features are too many or your data is changeable.
 
 
Let me know if you have more questions!
 
Thanks.
 
Yale

#3

Hi Yale, Thanks for the response. I did some more checking on things. I had a couple extra layers that made it so I didn't have a true comparison and by removing those, the difference is now 40 seconds. With the shape files, I can load the map almost instantly, and by converting the ShapeFileFeatureLayers to MsSql2008FeatureLayers, it now takes about 40 seconds every time I load the map.


Your second proposed solution is to keep the connection open and only close it at the last moment. Can you explain something to me? I'm passing the connection string into the constructor for the MsSql2008FeatureLayers. I'm not manually opening and closing it. I don't see any way around this. Is there something I'm missing?


I haven't tried the route of the cached feature layers, I am changing some stuff and so I think this is probably of limited value for me. I might change my mind on this for what I can at some point, but I'm not there yet.


Kimberly



#4

Kimberly, 
  
 I went through a lot of this stuff a few months ago when the initial implementation of SQL Server was very slow.  If you need the exact posting number, let me know.  First, no matter what I do SQL Server is about 2 - 3 times slower than shapefiles when doing the original map load.  That’s been about the same since the early lack of spatial index implementation was fixed.  Once my original map was loaded, I was testing the redraw time when zooming the map.  This, too, was really bad, but I found by implementing the default GeoCaching it improved many times.  It’s still considerably slower than shapefiles, but for us it seems to be acceptable so far.  One big difference is that as the map zooms in, the shapefiles redraw faster and faster, but SQL Server’s redraw times are fairly steady at all scales. 
  
 Allen

#5

Sorry, I forgot…for #1 there was a method added to build the spatial index via the MsSqlServer2008Layer itself (BuildIndex)…as far as I can tell there is no way to easily see if the index is built to avoid that time delay each time a table is loaded, but I haven’t looked at the issue too much.  We were thinking of adding it to a script somewhere when the table is originally loaded.  If you don’t call this method once for each table, it will be VERY slow.

#6

Allen, Thanks for your sharing, I appreciate it very much!


Kimberly, can you try the performance after build index as said by Allen? One way to see the index is already exists is to see the status in server side as following screen shot.
 

 
Let me know if any more questions.
 
Thanks.
 

Yale



#7

I have a spatial index already defined on each of my tables. They were not created using the BuildIndex method in the software, but rather simply through Management Studio. Is there a difference between that and what would be created with ThinkGeo's software?


Allen, can you tell me more about how you did the default geocaching? I played with it briefly a while back, but now I can't find how to do that in the code (and the only reference I can find to it on the forums is in another post of yours!)


Thanks,


Kimberly



#8

Kimberly,


Thanks for your post!
 
I think if you select “Spatial” for the Index type when you use the ManagementStudio, the result should be same.
 
And when you use the tool “Shape2Sql.exe” to export shp to Sql server, it also has an option to build index or not.


 


Following is the code using MapSuite to build the index:

 



string connectionString = @"Data Source=SQL2008SERVER\TGSQLSERVER;Initial Catalog=InternalDB;User ID=sa;Password=akeypmon1";
string table = @"cntry02Test1";
string featureId = "ID";
MsSql2008FeatureSource featureSource = new MsSql2008FeatureSource(connectionString, table, featureId);
featureSource.Srid = 4326;

featureSource.Open();
featureSource.MakeAllGeometriesValid();
RectangleShape bb= featureSource.GetBoundingBox();
Collection<Feature> features = featureSource.GetAllFeatures(ReturningColumnsType.AllColumns);
featureSource.BuildIndex(BuildIndexMode.DoNotRebuild);
featureSource.Close();

Let me know if you still have any more problems.


 
Thanks.
 
Yale

#9

Kimberly, 
  
 Below is how I’m doing it in my program that compares shapefile and SQL Server performance.  Supposedly this is a “basic” caching and it was suggested a few months ago that it would be possible to build one that’s more efficient, but that’s beyond me at the moment. 
  
                 FeatureCache featureCache = new FeatureCache(); 
                 featureCache.IsActive = true; 
                 featureCache.IsExtentCached(zoomExtent); 
                 sqlLayer.FeatureSource.GeoCache = featureCache; 
  
 Here “zoomExtent” is the original full extent of the map and I don’t think it ever changes.  One thing I would like to experiment with is to see if making this extent change at times (not sure quite when yet…maybe after doing a pan or zoom?) improves the caching performance.  But adding this made a big difference in the time it took to refresh the map when zooming. 
  
 Allen 
  
 Oh yes, I noticed Yale used “BuildIndex.DoNotRebuild”…I hadn’t noticed this before, but I presume it means to not rebuild an existing index.  I’ll have to give that one a try.

#10

Allen Thanks for your sharing! 
  
 Kimberly, DONOT hesitate to let me know if you have any problems using the GeoCache to enhance the performance. 
  
 Thanks. 
  
 Yale  


#11

I implemented the caching. Thank you Allen for the code listing, that was great! This has certainly increased the speed of refreshes, but loading is still very slow, still averaging about 30 seconds for the full map to show. I’m not sure what else to try at this point. 
  
 Thanks, 
 Kimberly

#12

Kimberly, 
  
 I have been experimenting with the caching.  As someone had said (I think it was Yale) the default caching doesn’t do much.  At the moment I am doing performance testing with shapefiles and we were getting slow redraws on a county-wide building layer, which has about 300,000 features AND is labeled; it only displays when the map is zoomed in quite a bit.  I have experimented with more elaborate caching schemes and had a 15 x 15 tile cache which sped things up immensely.  It does take some planning…building the cache when the map is first loaded is overkill since the buildings don’t show until the map is zoomed in quite a bit, so I would like to experiment with building the cache only when needed.  What does this have to do with SQL Server?  I would expect implementing a more sophisticated caching could speed it up as well.  I haven’t tried that, but it is on my list of experiments.  We definitely can live with the initial map taking a bit longer to load from SQL Server than shapefiles.  I’ll report back if I get to test SQL Server and caching…plus I haven’t tested SQL Server in the latest release. 
  
 Allen

#13

Allen,


Thanks for your sharing!
 
Just want to let you know that we have exposed the client cache in Overlay already in latest public release 3.0.362.See following posts for more detailed information.
gis.thinkgeo.com/Support/Dis...fault.aspx
gis.thinkgeo.com/Support/Dis...fault.aspx
 
Let me know if any problems.
 
Thanks.
 
Yale