Hello, I am having some issues with parcel Fabric Service. I have not been able to understand why the parcel fabric service generate a lot of time out. We notice a degradation of the service performance at afternoon, it start getting unresponsive and take several minutes to response for an action. ( we checked with IT and there is no process running at afternoon that could affect performance) We were having also some error on the server manager * Error performing query operation Wait time of the request to the service ‘Parcel Fabric/ParcelFabric_Records.MapServer’ has expired. * Processing request took longer than the usage timeout for service 'ParcelFabric/ParcelFabric_Records.MapServer'. Server request timed out. Check that the usage timeout is appropriately configured for such requests. So, we checked this information https://enterprise.arcgis.com/en/server/latest/publish-services/windows/tuning-and-configuring-services.htm and modify usage time from 10 minutes to 1 hour, because that is the time people use the service approximately, and wait time from 1 minute to 5 minutes. But we had a even worst behavior. My question, what would be the recommendation for max time a client can use a service and maximum time a client will wait? any suggestion? also we have not seen any issue with CPU or memory on the VM's so we can say it is not because system requirements. Thanks, Diego Llamas

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Parcel Fabric Service Time out, bad performance

DiegoLlamasOlivares

Hello,

I am having some issues with parcel Fabric Service. I have not been able to understand why the parcel fabric service generate a lot of time out. We notice a degradation of the service performance at afternoon, it start getting unresponsive and take several minutes to response for an action. ( we checked with IT and there is no process running at afternoon that could affect performance)

We were having also some error on the server manager

Error performing query operation Wait time of the request to the service ‘Parcel Fabric/ParcelFabric_Records.MapServer’ has expired.
Processing request took longer than the usage timeout for service 'ParcelFabric/ParcelFabric_Records.MapServer'. Server request timed out. Check that the usage timeout is appropriately configured for such requests.

So, we checked this information

https://enterprise.arcgis.com/en/server/latest/publish-services/windows/tuning-and-configuring-services.htm and modify usage time from 10 minutes to 1 hour, because that is the time people use the service approximately, and wait time from 1 minute to 5 minutes. But we had a even worst behavior.

My question, what would be the recommendation for max time a client can use a service and maximum time a client will wait? any suggestion? also we have not seen any issue with CPU or memory on the VM's so we can say it is not because system requirements.

Thanks,

Diego Llamas

Find more posts tagged with

General

Parcel Editing

Accepted answers

All comments

MikeVolz

Is this degradation recent and the Parcel Fabric has performed well for a while?

Or has Parcel Fabric always been slow since its implementation?

Geographic_Mythos

Looking at your screenshots, it may be possible you do not have enough dedicated instances (SOCs) for your fabric services.

From my experience with our Fabric, that low of a SOC count would be the first thing I would try adjusting if your server has room to do so.

Things you may want to think about that could be affecting your behavior in the afternoon: users reconcile/post process (these can queue SOCs quickly, and if you only have two, you may be 'waiting' while that process completes), large numbers of user requests querying fabric information (again, this can queue the SOCs so that they are waiting to complete other requests), or other applications making requests to the Fabric service, just to name a few.

benito

I've experienced similar timeouts and poor performance with PF feature services referencing large parcel type datasets (especially the associated line feature classes for each parcel type). The flavour of gdb I'm using in postgres. I found that when users open up an attribute table for a lines feature class of a parcel type the service would timeout. Further, these queries would take minutes to complete and choke up everything else. Here is an sql query to check what queries are troublesome:

SELECT
pid,
user,
pg_stat_activity.query_start,
now() - pg_stat_activity.query_start AS query_time,
query,
state,
wait_event_type,
wait_event
FROM
pg_stat_activity
WHERE
(now() - pg_stat_activity.query_start) > interval '60 seconds' AND
state = 'active';

Once I had the troublesome query returned from the above, I could then tune some indexes to speed things up. There's some complexity in the queries because of the branch versioning. I also prefixed the query with EXPLAIN ANALYZE to find out which indexes were being used.

Also, make sure that a VACUUM ANALYZE has been run on each polygon / line FC for each parcel type. I have had a situation where I copied in a parcel fabric constructed in a FGDB into a postgres gdb and the queries all ran very slow. I ran the VACUUM on everything and the queries that once took a couple of minutes to complete before the VACUUM, completed in a couple of seconds after the VACUUM.

In my case, the min instances for the featureservice in AGS is set to 8.

DiegoLlamasOlivares

Hello Benito,

we had an issue with database (Microsoft SQL Server) and DBA create the database separating everything in its own partition, data, Logs, temp logs, backups, ETC. And as @Geographic_Mythos mention, we add socks and time for wait time from 10 minutes to an hour. Also change heap size for server and parcel service to 256 and 128 and now, he are getting a better performance after Esri Recommended to change the recycle the configuration of the parcel fabric service every 12 hours instead every 24 hours, Now we see a more stable service and a better performance, we still see wait time, once a day,, instead of several times. Now users are able to work.

Hedstrom_Jeff

@DiegoLlamasOlivares I would definitely suggest experimenting the min/max instances per machine settings. We have only 2-3 users editing our parcel fabric and we have that number set at 10 & 10. 1 & 2 is likely way too low even if it was just a single user editing the versioned feature service. Try that and open up the Diagnostic Monitor pane in Pro and see if you have any more time outs or stalls occurring. I believe we have also had to tweak with the dedicated resources on the VM, in terms of putting more CPU and RAM on that server.

GrantCountyGISSup

Following. We upgraded our Enterprise to 11.5 from 11.3, ArcGIS Pro 3.5.2 as well as our EGDB. The biggest performance issue I noticed is that the Move Tool initialization time, Map Topology, and Layers are correlated. Picture below is a visual summary of what I tested. All of this data is with ESRI support, but they are telling me it's performance tuning and not in their scope of work. That is understandable, except for the fact this worked prior to 11.5/3.5.

I probably shouldn't have jumped to 11.5 so hastily, however, there were features that we have been waiting to come out.

DiegoLlamasOlivares

Hello Grant,

I my case, it was a bug found with SQL Server. and the Resolution: BUG-000176098 : SQL Server wait event resource_semaphore contention encountered because branch versioned queries on large tables with low selectivity result in the optimizer generating massive memory grants. and there should be a hotfix set for SQL Server error (HF-000006801) i will recommend if you have SQL Server, open a ticket with Esri and use my incident number 03986319 and asked for the HotFix

DiegoLlamasOlivares

Also, i created this second post https://community.esri.com/t5/arcgis-parcel-fabric-questions/create-indexes-on-sql-server-level-can-this/m-p/1634931#M2023 where ESRI team help us and told us about the bug and the hotfix.

Hope this can help.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.