Export Layout Poor Performance with Feature Services in Map Frame

[MatthewGeorge]

We're experiencing a significant difference in performance when exporting a Layout to PDF where a Map Frame uses Feature Services as data sources when compared with the same export using direct database connections for data sources.

A few details to help clarify the issue and the tests that we've completed:

- There is no noticeable performance difference between the data sources when using the map to interrogate and work with the data.

- There is no noticeable performance difference when rendering the data in the map.

- The larger and more complex the dataset the worse the difference.

- An example of the difference we've seen was using direct database connections for the layers in the Map Frame exported in 2 mins while using the equivalent Feature Services took 15 mins.

- The export seems to get hung up at the "Preparing export" prompt.

- We've run diagnostic monitor and can't see anything - the logs just hang at the "Preparing export" stage.

- Admittedly, we haven't done thorough testing on the other output types but reports from users suggest similar poor performance for Feature Services.

- Servers are all in the same data centre and there is very minimal network latency, hence using the same Feature Services for other tasks performing similarly to the direct db connections.

- Not sure if it's clear or not from the previous notes but the Feature Services being used are referenced (underlying data is stored in an enterprise geodatabase - SQL Server).

- We also did some tests in ArcMap 10.6.1 to see if the issue was just in Pro and we are actually seeing ArcMap crash at times instead. When it does succeed, the time difference to export a map we are seeing is similar to that seen in Pro.

- The issue was present as far back as Pro v2.3 and we are currently using v3.1.

- Enterprise deployment is 10.8.1.

So my question, has anyone else experienced similar behaviour or know what could be the cause?

[AubriKinghorn]

In the preparing to export stage of the export, the data in the map is being copied for the export. This is what allows the export to run in the background. Without the export running in the background you wouldn't be able to interact with Pro at all during the export time. Usually, copying the data is a fast process and isn't noticed, but in some instances it can take longer. And different datasets can take different amounts of time, as you noted.

If you don't want to run your export in the background, you can do it via Python. The export methods and samples can be found here https://pro.arcgis.com/en/pro-app/latest/arcpy/mapping/layout-class.htm. If you export via the python window the data won't be copied, so your export may be faster. However, you won't be able to use ArcGIS Pro while the export is going on. 

[MatthewGeorge]

@Thanks for reaching out @AubriKinghorn.

So does it copy the entire dataset? Or just the extent of the Map Frame? Because the differences I'm seeing would suggest it's copying the entire dataset which seems crazy to me if that's happening.

I'm also surprised that this even has to happen to be completely honest - even if it means a few seconds of Pro not being active versus waiting an hour for a map to export, it seems like a pretty ridiculous trade off. I can't ask users to run scripts from the Python window as they are mostly just basic level users and stepping them through that process is just not an option.

Might be value in raising this as an enhancement for 3.2? Or am I overreaching?

Cheers,

Matt

[AubriKinghorn]

You can absolutely submit an idea to have the export run in the foreground instead of the background, or any other enhancement that you think might be helpful.

If I remember correctly there was an idea to have the export run in the background once too, which is part of the reason this got implemented. In some cases an export can take a long time, especially for posters or wall sized PDFs and so it was frustrating for those users to have the application tied up the entire time. 

You can also reach out to technical support, they can investigate your data and setup more carefully to determine if there are other factors at play. It's completely possible there is a bug or two somewhere in the software, or a more optimized way to connect to data to make things faster. 

[MatthewGeorge]

Thanks again @AubriKinghorn.

I can understand how running it in the background is valuable if the times to export aren't blowing out so much. The bit I still can't wrap my head around is that when I perform a copy features or any other GP task on the Feature Services, the differences in time to complete is negligible when compared to the direct database connections. As you've said, there might be a bug somewhere causing the hold up too.

I've raised it with support and they've escalated it to ESRI Inc. so hopefully we get some sort of resolution!

Cheers,

Matt

[AubriKinghorn]

Thanks!! Hopefully we can get you some better answers from support soon!!