Hello guys!
We have an issue where our actionsite is growing larger each day. As of now we have a “warning” in our Health Checks Dashboard.
Here are some details:
Now I was wondering, what is the recommended size of the actionsite, I mean, the M.O Site in this case.
We want to follow some best practices.
Thank you.
I recall a recommendation from years back suggesting to keep it below 25Mb.
If you are creating most of your content as a Master Operator then that can lead to a larger actionsite. Custom content such as baselines, analysis, groups etc as well as any actions, especially multi-action groups created from deploying a large baseline can quickly increase the actionsite size.
This was an issue I had a long time ago where most day to day stuff was being done by MO accounts. We stopped using MO account for day-to-day work and moved all the content we had created, in particular baselines that were containing anything up up to 200 components, to new custom sites and that quickly reduced the size of the actionsite.
I guess that 25mb is the maximum size recommended, heard that once from someone on support, but couldn’t remember.
As per the contents in MO, yes, we are facing this same issue, lots of baselines with multiple actions being placed in MO. I already recommended the team to move away from this approach and create more custom sites, but so far, no progress.
Thank you.
It’s really difficult to give a “general” guideline as much of it is specific to the type of content in the Action site, and how frequently it changes.
It’s fairly common to have many Analyses that are globally activated. These take space in the Action site, but because they often have reporting frequency turned down and they don’t change often, these are not as impactful.
Rapidly creating & stopping actions as a Master Operator has a more significant impact, because these are changes to the Action site which causes all of the Action site content to be gathered and re-evaluated.
One of the efficiencies we use for site gathers is to only gather “differences” between different versions of a site; but the server only maintains diffs against a specific number of previous site versions - I forget the number but for example let’s assume it’s six versions. If you have several master operators rapidly creating actions, it’s easy to go past six site versions while a number of clients don’t gather the site diffs, and once the client is more than six versions behind it cannot just gather the diffs anymore, it has to gather the full site over again. When repeated over thousands of clients that is significantly more load on the network.
If the actions had instead been issued by standard operators instead of master operators, those actions would be spread out over several operator sites, and there’s a higher likelihood that most clients could have gathered diffs of each onsite instead.