I have a couple of new server machines that I'm setting up with ArcGIS Server and SQL Server for our enterprise geodatabases. I'll be migrating our map services and geodatabases to the new servers but I have been doing a bit of testing first. In testing the time it takes to render a few different layers from a dynamic map service, I'm surprised to find that my simple feature classes stored in SDEBINARY still have a performance advantage over using the GEOMETRY spatial type. Same finding as when I went through all this years ago with older hardware and software. In some circumstances the difference is still dramatic.
The servers are running Windows Server 2012 R2, SQL Server 2014, and ArcGIS Server 10.5.1. The geodatabase is 10.5.1.
Anybody coming to the same conclusions? Or have you found the other spatial types to be better?
Ryan Kelso One thing to also consider is that many non-ArcGIS clients cannot read SDE BINARY and you have make sure that you update/maintain the indexes (spatial and non-spatial) via ArcGIS tools. If you use SQL Server Geometry then the SQL Server native tools could be used.
There are some other potential issues, creating DB views on SDEBINARY is not possible via the GP tools.
If you have specific issues, I would recommend opening a new Esri Support case and having the analyst take a look.
There are also many threads on this subject on GeoNet with any different results.
Thank you for the comments, George. Being pretty much an accidental DBA, this kind of insight is really helpful. I have definitely been through many of the threads on this subject over the years, my goal was to get a more current take on the issue.
I have a contour/topography layer in my map service that exhibits the most obvious difference between sdebinary and geography. With over 800k rows of vertex-heavy features, with sdebinary it has very acceptable performance and with geography it can be unusable depending on the extent.
One thing you could try is to "cut" up your contours into "smaller segments? This may help with the draw time as each segment is smaller.
Another option is to have a generalized copy of the contours for "display" and that would remove a lot of the vertices.