How to improve performance on a dashboard with a very large point layer?

[ChipMorgan65]

I've got a large feature class (>1million points) that I'm using with using Dashboard (I need to increase the number of points as I expand the geographic area being covered). Yeah, obviously, this is pushing Dashboard way beyond its comfort zone.

I have a series of Dashboard filters to control how much data is displayed, but the filters are not having the expected (well, hoped for) benefit in response time. It doesn't appear to be downloading all of the data in the layer (looking at Windows Task Manager), but there are long gaps in the response time before the operation completes (all appropriate points are displayed on the map, in a table, etc.). 

I've recently been reading about applying attribute indexes to AGO content using REST calls (here). I understand the basic concept of indexes (to avoid a table scan, i.e. returning all of the rows in a table for the client to have to filter).

However, I'm fuzzy about translating that into action on a dashboard. For instance, if I have a Dashboard filter on a field called "state" (Georgia, Alabama, Tennessee, etc.), is it just a matter of defining an attribute index on the state field?

How about if I have a second Dashboard filter for another field?  Just add a second filter for that other field?

If I have a group-by filter on field A with a sort by on a field B, is my index going to be: A, B? 

How can I peek under the hood and see what AGO is attempting to retrieve?

I can provide additional information as appropriate.

[CESPEDESLUISITD]

Hi Chip,

I ran into the same issue as I was using a local sde layer on a map service with millions of records. The back and forth between AGOL, the server and the user request made it impossible to zoom in, filter, etc.

The only workaround I found (and its not perfect) was to shrink the size of the table structure to the bare minimum, upload the data to AGOL and created a hosted layer, use a date filter to only query the current year at run time, use clustering for all the points instead of showing them all. 

This sped up the process of loading and filtering.

You can give it a try. I know its not what you would probably want as myself did not like to change the functions of my previous written application to this dashboard solution. But I have to work with what I have.

Other than rewriting this in javascript, that workaround still working for me. 

Good luck

[ChipMorgan65]

I appreciate your suggestion!