Does anyone have the SD option "scoreboard_entry_limit" installed? If yes, are you using the default 200 or have you modified the number (please list value)?
I am just trying to get a feel if other organizations put a limit on how many nodes can be placed on a dashboard. As well as what that limit is to be able to bring this back to my organization to bring more formalization of standardizing the scoreboards into play. We use CA SD 14.1.2 and with the ability of users being able to create their own queries we are over 850 stored queries. We are starting to see multiple queries for the same searches and want to start creating standard practices so the system doesn't get out of control quickly.
Let me know if you could benefit from the below technical document in regards to your query below which ash vast information regards to scoreboard
Title: Most Common Issues When Working with Scoreboard
You might be interested in below technical document which is closely matched to your query.
Sub: Upper limit to the number of scoreboard
Though the version was not defined in the above documents but I guess the parameters remain same.
Let me know if this helps?
Thanks, I will check the articles out.
Since the 'scoreboard_entry_limit' option only pertains to customizing Scoreboards (ability to add a new node or folder), it will not stop people from creating new stored queries.
In my opinion, 200 is a reasonable # for this value. Anything larger than that and the user Scoreboard would become to long/convoluted to navigate.
Paul, are you saying when someone saves a query from for example Search>Incidents it adds a new node to the My Saved Queries folder, this does not count towards the limit? I am not sure how this is any different than File>Customize Scoreboard and adding a pre-existing query to a folder.
My first thoughts on this one will be to not allow simple users to create their own stored queries but only be able to add pre-existing to their scoreboards nodesas you can't expect fro you end users community to have a full understanding of TSQL statement and their impact to the system.
On top of the duplicate that you mentioned above such users queries are often poorly written with direct impact of you SDM performance.
We have the case in the pass with one of our large client where all the performance issues encountered was finally linked back to such bad queries using as an example sym vs. id and/or high consuming join like:
category.sym like '%network%' OR category.sym like '%firewall%' OR category.sym like '%VPN%'group.last_name ='1T servicedesk'
category.sym like '%network%' OR category.sym like '%firewall%' OR category.sym like '%VPN%'
group.last_name ='1T servicedesk'
they may look insignificants individually but when you get a large number of those running every 3 mn you will start to feel it.
It's was on 12.5 to fix the problem at that time but we did have to review several thousand of stored queries individually and optimize them one by one. Believe me this was really time consuming.
My 2 cents,
As per a recent support case I had (creating a tecdoc but not published yet):
When you are creating a new scoreboard node and you get displayed following error message:
"The scoreboard has reached the maximum number of nodes and folders; additional items are not permitted."
No errors in stdlog.
This means that you have reached the maximum number of scoreboard entries.
Out of the box, the default value is 200.
Note that the limit is related to the scoreboard nodes number and not to the stored queries number.
As pointed, there is an environment variable which can be defined to modify the out of the box limit.
The variable is called:
You could consider to set this variable with a lower value in case you need to keep under control the number of scoreboard entries added by Analysts as per the performance impact.
The variable is included as one of the options in the Option Manager (SDM web interface - Administration Tab)