ArcGIS Pro - Performance issues / SQL Server 2012

[#1]

I’m curious if anyone has run into performance issues with ArcGIS Pro as it relates to accessing data over a network to a remotely located SQL Server 2012 DB.  The Geoprocessing issue in particular we are trying is simply doing a ‘Select By Location’ of parcels against another layer, and it is taking almost 10 minutes; in ArcMap it takes about 20 - 30 seconds.  It is not a big selection, only 300 polygons.  We have done the following troubleshooting tasks:

• Upgraded to latest version of Pro (2.1.1)
• Worked on a local version of parcels (worked really fast doing this – points to network issues)
• Deleted Geoprocessing History in Pro
• Created spatial index on parcels in Pro
• Increasing the
• Started a brand new project and only brought in a few layers to do this select by location task
• Had other staff in our department and other departments – unanimously this task was super slow when accessing this SQL Server database
• Increased virtual memory on SQL Server

The SQL server is located remotely, with multiple departments accessing it.  Pinging the server shows a 4-5 MS return time which is considered excessive (over .05 - .10 MS), but again, ArcMap works fine.

We suspect the problem has to do with how ArcGIS Pro interacts with the network (people say Pro is "chatty").  I’m not finding a lot of literature on how to configure ArcGIS Pro any more than we’ve already done.  I do see a similar Geo-NET article here, though the culprit for this case was .lyr files that referenced layers from an Oracle DB.  I’m wondering if anyone out there has experienced these issues with their network and / or SQL Server and has resolved it?  Below is a screenshot from ArcMon to illustrate the specific processes that took the most time, if that is helpful.

I really do like using Pro, but these kind of performance issues is really a hindrance to doing the full switchover.

Thanks,
Dan

[ThomasColson]

Are you able to use TCPView and look at connections when doing the same exact task in Arc and Pro? 

Wireshark will give you a more detailed analysis though, but most orgs don't allow it. TCPView will just give you "yup, it's making more traffic calls than Arc". I do not have this particular tool issue, but have found that against SDE, Pro is substantially slower in doing the same things that Arc does in less time, for pretty much everything. What I'm seeing, and guessing at, is that for every time Pro "Touches" a feature class from SDE, it pulls down (every single time) the entire definition, metadata, etc....substantiated by the how many more requests are going to GDD_ITEMS when I have Pro open, whereas Arc is doing some sort of xml caching when you're working with a feature class. I'm throwing darts here, but on my list is to put together a monitoring suite and isolate some of these things down to specific processes and ports. However, you're best chance to an answer will be through ESRI TS. Keep us posted, may save others from logging the same case. 

[DanHoffman1]

Hello Thomas, thank you for your response.  I will give TCPView and Wireshark a try.  To be honest I've already gone the ESRI TS route and since the issue seemed to be with the network, the analyst wasn't able to go further with me...short of installing pro directly on the remote machine that had SQL server installed on it and see if it goes any faster.  I wanted to cast a wider net using Geo-Net and see what this community had to say, then maybe re-open this case when I had more info.  Thanks!

[ThomasColson]

If the issue was with the network, then Arc would take just as long.