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.