Parcel Fabric Performance Issues

[JohnMax]

I created and am currently testing a parcel fabric for my organization.  Works very well in a file geodatabase but we need multi-user editing.  When I use the feature service editing it becomes extremely slow.  For instance, aligning a simple rectangular parcel takes seconds in the FGDB but 18 minutes using the feature service.  I want to use the parcel fabric but my users will not accept this slow performance.  Any advice as to why this is happening and/or possible fixes or workarounds?  I am using version 1 because I am currently running Portal 10.7.1.  Thanks. 

[jcarlson]

John,

We experienced similar performance issues with our fabric early on. We were able to identify a couple of reasons for this.

1. The quality of the input data. Our fabric was built from a topology-enabled feature dataset, rather than an ArcMap parcel fabric. Unfortunately, the prior staff we inherited this data from had not been in the habit of validating their topology very often, or when they did, were simply marking all errors as exceptions. As a result of this, many vertices in our fabric which should have been coincident points (parcel/lot corners, ROW frontages) ended up being offset by extremely small distances.
   To address this point, we simply ran Validate Extent on an area before attempting any alignment tools. This collapsed vertices within the cluster tolerance into truly coincident points, and subsequent alignment times were much quicker.
2. The number and size of parcel types. When working with a feature service that has editing enabled, the service needs to cache every visible feature in its entirety, regardless of how much of it is visible in the extent. With very large or complex features, this can cause a significant hit to performance.
   Our fabric initially had several parcel types that really didn't require or benefit from the fabric's document-based, historical tracking capabilities. Examples would include things like Political Townships, Hydrological Features, &c.
   By constraining our fabric to only features which were actually being created/retired/modified by recorded documents and moving other features to a separate feature dataset, our alignment tools ran considerably faster, as the service was no longer needing to cache massive features spanning large swathes of the county.
   I should also mention, there was one layer which was very important our fabric (right-of-ways), but which, because of how previous staff had used the layer, consisted of massive multipart features. We are in the process of splitting these into their constituent conveyances, dedications, and vacations that actually comprise the right of ways, but in order to temporarily alleviate the performance issues, we have split the features into smaller pieces, which has also improved processing times.

[jcarlson]

PS - If you do wish to maintain all of your layers in the fabric, v2 allows you to include "administrative" parcel types in your fabric. This, however, requires an upgrade to 10.8, as it appears you are aware. You might consider temporarily maintaining the layers separately, then bringing them back into the fabric as admin parcel types once you upgrade.

[MichaelVolz]

John:

Are you implementing the parcel fabric in a work from home scenario using a VPN due to Covid19 or are you working directly on your network?

[AmirBar-Maor]

Hi John,

If you are using the first version of the parcel fabric (version 1 with Pro 2.4 and server 10.7.1) you might have an issue with record features that are associated to too many parcels. To confirm this open the attribute table for the records feature layer and sort them using the Shape_area field. especially if you are coming from ArcMap parcel fabric, you might have a <map> plan that is causing the performance issue. Just delete all records that have a huge geometry, reconcile-post, and recall the spatial index for the records. 

If you are seeing general performance issues (drawing, selection etc.) then the problem might be anything from a bad network cable to a bad spatial index.

The parcel fabric in Pro uses SIMPLE FEATURE CLASSES - any performance issue is unlikely to be parcel fabric specific.

Technical support might also be able to help.

Amir