Credit/storage tips and tricks?

[Marokapara]

Hi AGOL community,

I wondered if anyone had any tips or tricks to make the most out of your layers/storage to not eat up credits? One good one someone suggested to me was converting large layers to hosted tile layers.

We don't do any geoprocessing online so that's not a concern credit wise. Or a good way to find out what layers/maps are using up the most credits?

Thanks in advance for your help.

[David_McRitchie]

I would definitely recommend taking a quick look at your content and checking the credit documentation.

Generally, we see that storage of Hosted Feature Layers can often lead to unexpected jumps in credit cost, particularly if someone accidentally uploads a large layer, or is uploading numerous testing layers and not removing old content.

I would also check if you have Editor Tracking enabled on layers as this can increase the file size.

Of course it can be difficult to tell when this happens, so I would recommend checking this community post as it provides a useful Python code sample that can be used to return the file size of content within a Portal.  Alternatively you could do the same with Hosted Feature Layers that have not been accessed for a period of time. The following Community post also has a useful code sample for implementing this.

[Marokapara]

Hi @David_McRitchie , Thank you for your reply. I read through those links. I haven't run the python script yet. I'm not a Python user yet. Do I run this in notebook?

Regarding editor tracking what's the difference between 2nd and 3rd item here under editting and why is the third default to greyed out with an astericks.

The first screenshot is a view layer. The second screenshot is the layer the view was made from.

When skimming through the layers we have I found a vector tile package 170.841 mb and a tile layer (hosted) 170.737 mb. I've removed the package now. I wasn't sure if removing it would have negative effects on the hosted layer, but after doing some reading via the links you set I realise I could have removed that and a few other packages earlier to cut down on credits getting eaten up.

[David_McRitchie]

Hey Marokapara, Yes you can run the script in a notebook.  If you are interested in getting into the Python side of administrating the following Learning Plan is a great starting point.

In regards to the editor tracking, since the first image is from a view layer this will take the editor settings and attributes of the original layer. We, therefore, couldn't have a View Layer receiving attributes on who last edited the view, if the original Feature Layer has editing tracking disabled, as this information could not be stored.

[ChristopherCounsell]

Covered in a lot of detail here:

https://esriaustraliatechblog.wordpress.com/2021/06/22/which-arcgis-online-items-are-consuming-the-m...

You can generate reports and identify costs based on feature storage and attachment storage.

The common things to look at are:

• Number of features
• Number of fields
• Complexity of the geometry (think of 1 point, vs millions of vertices that make up a complex feature). Generalization can smooth the geometry out.
• Editing and editor tracking settings
• Layer optimization
• Sync, especially over time
• Attachments (stored and costed separately)
• Alternative service types, such as vector tile, if feature capabilities are not required

Generally speaking two main scenarios for big feature credit sinks:

• You upload a very large, complex feature class as a hosted feature layer. It's just massive.
• You have an old, frequently edited and downloaded feature class, that has a very large amount of backend tables for sync and editor tracking. You can fix this by toggling sync and editor tracking to recreate the tables (but also lose all currently downloaded replicas, etc).