Branch Versioning: MapServer export with gdbVersion 4-6x slower than default version

[ag-maile]

Hi everyone,

I'm working with a branch versioning setup on ArcGIS Enterprise and ran into a significant performance issue when switching between versions in a web application built with the ArcGIS Maps SDK for JavaScript 5.0.

Setup:
- ArcGIS Enterprise (federated server)
- Branch versioning enabled on a feature dataset
- Multiple named versions (e.g. `editor1.review_branch`, `editor2.field_update`, `qa.validation_pass`)
- Web app using `VersionManagementService` to switch versions

What I observed:

When querying the FeatureServer — whether using the default version or a named version — response times are fairly consistent and acceptable. The behavior is similar across versions.

However, when switching to MapServer (using `MapImageLayer` with the `gdbVersion` parameter), I'm seeing a dramatic difference:

- Default version (no `gdbVersion`): ~1.5s response time — fast, presumably served from server-side cache
- Named version (`gdbVersion=editor1.review_branch`): 4–6s response time on every request

The moment I add `gdbVersion` to the `MapServer/export` request, the server appears to renders dynamically every time.

Has anyone run into this before, or does anyone have ideas on how to improve response times for versioned MapServer export requests? Any suggestions — whether on the ArcGIS Server configuration side, geodatabase tuning, or a completely different approach — would be very much appreciated. Thanks!

[GlenterpriseUK]

Hi @ag-maile,

What you are observing, is expected behaviour with branch versioning. When you do not specify a gdbVersion, the MapServer can use cached/optimised rendering. As soon as you pass a named version all the reuqests become version specific so ArcGIS Server has to dynamically resolve the edits and draw the map each time. That is translated into the delay you are noticing.

You can use:

- Feature Layer (Feature Server) with gdbVersion and let the client handle rendering

- Reduce the Map Layer (Map Server) as much as possible in terms of symbology, labels, layer count

- You can Reconcile/Post regularly so the versions do not get to "heavy"

- You can also tune the service and Database

I would advise a combined/hybrid approach to go for MapServer for the default version and FeatureServer for versioned workflows.

Regards,

Glen

[ag-maile]

Hi @GlenterpriseUK ,

Thanks for your explanation.

I understand why specifying gdbVersion prevents ArcGIS Server from using the optimized/cached rendering path. However, I am still struggling to understand whether the behaviour I am seeing is actually expected.

Regarding your suggestions:

• Feature Layer (Feature Server) with gdbVersion – this is already the approach I use for editing. The idea is that users initially work only with the MapServer (read-only map image). Only when they decide to edit a layer do I switch that particular layer to the FeatureServer. This works perfectly for the default version (or non-versioned referenced feature services). My expectation was that the same workflow would also work with branch versioning.
• Reduce the Map Layer – unfortunately there is not much left to optimize. The symbology is very simple, there are no complex labels, and the number of layers already reflects the minimum required by the business logic.
• Reconcile/Post regularly – this would make sense for long-lived versions with many edits. In my case, however, the version is almost identical to DEFAULT and contains only a single edit in one layer, yet the MapServer response time still increases dramatically.
• Tune the service and database – I have already optimized the service and database as much as I reasonably can. The only remaining option would be allocating more CPU resources to ArcGIS Enterprise, but I am not convinced this would fundamentally change the behaviour.
  This brings me to my main question.

Should a branch-versioned MapServer be considered unsuitable for interactive applications? If so, what is the intended use case for it?

If not, then I am trying to understand where the bottleneck is. Even with an almost empty branch version (essentially a copy of DEFAULT with one modified feature), I would not expect such a significant rendering penalty.

Is this simply an inherent limitation of branch versioning, or would you consider this behaviour abnormal?

Regards,
Maile

[TanuHoque]

@ag-maile 

how long does a feature service query operation take when you use the default or a named version?

you are not referring to a 'cached/tiled' map service here - I just wanted to double check.

[ag-maile]

Hi @TanuHoque ,

Thanks for your reply.

The Feature Service performs well in both cases. Query operations against the DEFAULT version and a named branch version have very similar response times, and I have not observed any significant performance degradation when using gdbVersion.

The issue only appears when requesting map images from the MapServer with a named branch version. As soon as gdbVersion is specified on the MapServer request, the rendering time increases significantly, even when the named version contains only a single edit and is otherwise identical to DEFAULT.

And yes, I am referring to a dynamic Map Service (MapServer) of specific gdbVersion, not a cached/tiled map service.

This is why I am trying to understand whether this behaviour is an expected limitation of branch-versioned MapServer rendering, or whether it indicates a configuration or performance issue.

Regards,
Maile