Mapservice in AGOL Dashboard App Painfully Slow

[MichaelVolz]

To All AGOL Users:

I have an AGOL Dashboard application that is consuming a hosted mapservice (quite simple) that is used simultaneously in multiple widgets.  The mapservice performance in the Dashboard app as well as at the REST endpoint is painfully slow.  Has anyone using the AGOL Dashboard app encountered this issue?  If so, how were you able to resolve the issue.

[MichaelVolz]

The performance of the mapservice has not improved.

Do you update your feature layer on your AGO site through an editing application?

The datasource for our mapservice does not get edited in any type of AGO app.  The original datasource gets updated in a GIS desktop application (Add-In) that stores the data in an Access database (not a Personal geodatabase).  This data gets copied to an AGS registered file gdb every 5 minutes.

[Reynaldde_Castro]

So, the map service is using this file gdb as the data source for ArcGIS Online?  Are you updating attribute information only?  Does the webmap that you use for the dashboard perform slow as well?

We use a software, FME Workbench, to push data on a hosted feature layer on our AGO site.  The feature layer is consumed by our webmap and out to the public.

[MichaelVolz]

So, the map service is using this file gdb as the data source for ArcGIS Online? Yes

Are you updating attribute information only? No, I am doing a truncate (delete records) and append of the file geodatabase using a python script with MakeXYEventLayer from the Access database.

Does the webmap that you use for the dashboard perform slow as well? Yes, as well as viewing the mapservice at its REST endpoint.

You say you use FME Workbench to push data to the hosted feature layer, but what software do you use to actually update the data before you push it to the feature layer?

How is your data stored before it is pushed to the hosted feature layer (e.g. file geodatabase, SDE geodatabase, personal geodatabase, shapefile)?

Your feedback is greatly appreciated.

[Reynaldde_Castro]

Let's take a look where the slow down could be coming from since you have several things going on.  I like to break down the parts to get to the bottom of the problem.

1. I would create a copy of the filegdb and server that to AGO. Don't include this to your update process. Create an AGO map using this filegdb.  See if this map is just as slow.  If it is then move away from filegdb. If it performs without hiccups then
2. Try increase time between updates.  There could be some lag in the process.

I have users that update the attributes to a table via web, join feature and table, and update the AGO feature based on the join.   Table is stored on sql server and feature is stored on sde. We only use filegdb for local storage copy of data.

Are you using lat/long for your location?  Have you tried exporting that as a CSV file and just consume that file directly from AGO?  I have another site that consumes a CSV file and let AGO refresh the layer at any time interval I set.  The CSV should be accessible from the web.  If you are using lat/long then that could be a cleaner method for what you are trying to achieve.

Refresh layer is one of the AGO layer properties on your webmap.

[HeathAnderson]

We are facing a similar issue.  I am sorry if I am not clear on the solution.  Was it to move away from the fgdb?