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-servi... 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

MichaelVolz

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.

DiegoLlamas

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.