Branch version takes too long to post edits

[samshrma998]

We are editing a utility network data and having issues while reconciling and posting branch version.

It is posting what is too much of time and edits are also limited (max 50 edits).

The process used to smooth earlier and no changes have been to configuration or database.

[RPGIS]

Hi @samshrma998,

Here are some things that need to be taken into consideration when editing from the field that you may or may not have thought about.

1. Cell service - if there are instances of weak or no cell service then this can cause issues when editing in the field. If the service is too weak then you may need to try and reconfigure the service by testing these parameters:
   1. Reducing sample size than what the default sample size is.
   2. Decreasing when the layers draw when zooming out
2. Using offline data collection - if you are using offline data collection but the field crews are not regularly pushing updates then that could be causing problems. When there is too much data being collected in the field that isn't regularly updated then the amount of data is too large to send. You may need to reconsider what kind of versioning to use in this instance.
3. Too many edits being done at once - if there are too many edits happening simultaneously then that could potentially cause issues as well. If branch isn't working, then try using traditional versioning to see if that makes a difference.

[samshrma998]

Thanks @RPGIS for recommendations. 

1. For weak service, there is no issue or latency while editing. Though we reduced sample size with no luck.

2. Offline data collection is not part of our current workflow.

3. We tried using multiple version. Some version having just 5-6 edits which also have same latency while posting. For less than 10 edits, it takes around 7-8 mints to post edits.

[RPGIS]

Hi @samshrma998 

Can you possible break down the rough details and workflow, starting from the generated service to editing in the field? Things such as:

1. Number of layers/datasets
2. symbology type
3. imagery used
4. layer drawing scales
5. number of editors
6. portal (enterprise vs AGO )
7. service type ( hosted vs reference )
8. Applications used ( field maps , survey123, workforce, etc )

The more information the better so that either I or someone else can help possibly pinpoint the exact issue.

[MarceloMarques]

@samshrma998  - Branch version takes too long to post edits

The branch version feature service that you are using might be too busy, so you might need to adjust the minimum and maximum number of SOC processes. Also, consider changing the service type from polling to dedicated; this way, the service will have dedicated SOC processes.

Also, you need to perform regular maintenance of the ArcSDE Enterprise Geodatabase often, you need to gather new statistics weekly and rebuild indexes monthly.

If you continue to experience performance issues, then please open a ticket with esri tech support to investigate further.

[PierreloupDucroix]

Hello,

Do you have any solutions or suggestions to share?

We're experiencing the same latency issue when posting a limited number of changes. It can take 10 to 15 minutes to post a minor network edit, which can cause a client-side (AGPro) timeout.

We've rebuilt the indexes and recalculated the statistics.

We've also ensured that the SOC count and performance are correct.

The same posting delay occurs when we try to post via the REST endpoint.

[RPGIS]

If you're experiencing latency issues then you might need to try the following:

1. Reduce the number of records returned by the service, as @MarceloMarques has mentioned. Too many records can result in poor performance.
2. Set the display scale to a reduced scale. Too large of a scale can impact drawing as well as editing. You can try to publish the editing feature service to a reduced scale and publish a vector tile service at a greater scale.
3. Reduce the number of editable versions. Recommendation is no more than 3.
4. If cellular strength is a common issue, try publishing a traditional version. Branch versioning can work but is typically limited to the strength of a cellular network.
5. In conjunction with publishing both an editable feature service and vector tile service, publish the feature service with only required fields and filtered values. Publish the vector tile service as needed.

The methods mentioned above are the few methods that I'm familiar with regarding services in general. I can ask a few others for their take as well.

@jcarlson @ChristopherCounsell @HaydenWelch @DanPatterson 

[PierreloupDucroix]

Thank you for your answer.

I will try to give more context :

We are using a Utility Network (UN) feature service that is edited in ArcGIS Pro. --> There is no cellular network or any other network quality issue as far as I know.

Working with UN requires that the feature service used in Pro maps contains all feature classes and all attributes. They are only filtered in each subtype layer's field view. Additionally, we worked a lot on improving the drawing, scales and display of the layers in the map. I note that reducing the number of records returned by the service can help too.

The main latency issue we have, is when reconciling and posting a named version, that contains a bunch of edits, to the Default version.

--> You are talking about reducing the number of editable version, what do you mean ?

I don't know if it may be related to the reconcile/post process of ArcGIS Enterprise, the database tuning, or related to a UN thing (like having subnetworks triggering attribute rules in the named versions...).

[RPGIS]

So versions follow what's called a version tree, if you didn't know that already. What that breaks down to is that more versions equate to more delta tables. Delta tables are transactional states from the main parent table. You basically create a new state every time a version is created. With that being said, this can greatly increase the size of the database hence why it is recommended to compress the database nightly the more versions you have.

The other thing is if you have multiple branch versions trying to apply edits then that can cause issues with reconciling data because to many edits can be applied at any given moment.

The only other thing I can recommend is to set your rules to "Exclude from application evaluation" so they trigger server side and not in the application.

If problems persist then try going traditional over branch and see if that makes a difference or try using vector tiles. 

[PierreloupDucroix]

I'm not sure the version tree / delta table apply to branch versioning, since only Default version is the parent of all named versions. It is more like a big archiving, then there is no need to compress, but instead we can prune records with the new Prune branch History toolbox