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.

[HaydenWelch]

Would you be able to possibly share some of the logs from Pro? You can get them from the diagnostic monitor under the help tab. That would help pinpoint if it's a network issue or if it's some crazy circular rule triggering that's happening due to asynchronous edits coming in and locking up attribute rules.

I've seen interdependent attribute rules absolutely kill performance when every edit cascades to 10 different feature classes, and that's when it's all in a local file database. Doing that over the network can seriously cripple Pro.

[PierreloupDucroix]

Hello,

here is the log file from Pro, from the starting of the version posting to the error message :

and AGS log : 

SEVERE

30 juil. 2025, 14:55:59

StopServiceEditing failure (sessionID: {AF268C58-99C5-4DAB-A4CD-0511979B0103}) (User session application lock in progress - operation not allowed) Session Application lock in progress [Session application lock in progress - operation not allowed]

--> exactly 10 minutes between Post and Error : this is why I think of a client-side timeout in this case, but running the Post in REST will succeed after 15 minutes or more.

[RPGIS]

Do you have users actively editing and either not closing their sessions or have hanging edits? That can sometimes create locks which may be a reason. Try asking everyone to disconnect and then reconcile and post.

[PierreloupDucroix]

In a branch versioning environment, only one user is allowed to edit in a version at a time, so there should not be issues about parallel active sessions. Additionally, Default is protected.

I can sometimes see exclusive locks on named versions, but they should be managed by the system. 

The only thing I think about is having multiple users with version management administration capacity and editing Default, or posting at the same time... But disconnecting everyone in order to post versions should not be necessary.

Also, there should be separate capacities for posting and for Default editing and administrative right...

[RPGIS]

I didn't think to suspect that at all. You might be right and that could be causing the issue. If there are some attribute rules designed for feature to feature edits in conjunction with multiple users editing then that may be the cause.

[SStopyak_BruceHarris]

Here are some basic things I always do to troubleshoot poor performance for services in general:

1. Look at the ArcGIS Server logs and see what (if anything) is being logged as Warning or Severe.
2. Open the performance monitor and observe the CPU and RAM utilization of the Enterprise servers and the SQL Server machine (or whichever RDBMS you run). 
3. Look at the CPU and RAM specs for the same machines above. 9 out of 10 times if you're noticing poor service performance of any sort, one or more of these machines will be under-provisioned. For production use I provision at 8-core 32GB RAM and increase as needed. That is my bare minimum for all production machines except a DMZ web server which can be 4-core 16GB RAM usually.
4. On the ArcGIS Server machine, open the service in Pro while watching the performance monitor to gauge what your interaction with it is doing to the ArcGIS Server. Some of the performance hit will be Pro itself but if you're seeing a drastic impact to performance just zooming and panning around, you are likely under-provisioned.
5. If you aren't under-provisioned, go ahead and bump up the min max dedicated instances incrementally (within reason) until the desired performance is achieved. make sure it is dedicated, not shared, as well. 
6. Optimize your feature services. Be frugal with layers and display scales. If it isn't absolutely needed, take it out. Minimize or remove anno especially. Turn off every layer but one by default. The one you leave on should be a basic layer with few features that can be use as a visual for locating your AOI. Something like a County boundary is good. 
7. Make sure you aren't publishing any layers that have no features. Make sure the spatial extent for layers is calced ok. If not, recalc them. Empty layers can't calc an extent so at least add one dummy feature within your AOI and recalculate the spatial extent.
8. Make sure you aren't running overzealous security software on the servers

Maybe some of these general things can help too. Good luck!