- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-15-2022 06:18 AM
Hello All,
I am Using Performance Analytics for Vulnerability response. There is an OOB Daily report (Vulnerability Management report) which runs with an indicator source (vi. active), In which the condition is only( Active =True), which fetches all Active vulnerability items (In my case 4.6 M records); There are two jobs running on Daily basis( historical and daily job), all of a sudden, it stops the data fetch while I investigating this, we found the limit is only 750,000 records and our count goes beyond that number. I am aware I can increase this limit, but my question is,
1. Can I Increase this number by 5M, and run this Job? Of course, there will be a performance issue and I can run this over my lean time. but this is highly needed to see what is my overall VI in the organization on daily basis.?
2. If we need to add a couple of filters on top of this condition in the indicator source, I am getting the outcome that I need.
3. SInce the Servicenow is an enterprise tool, how this Vulnerability item or the huge number of data are fetched and used. Need the best practices advice?
Regards,
Paul
PaulSylo
Kindly mark "helpful", if this helps, or Mark as "Accepted " if it solves your issues !
Solved! Go to Solution.
- Labels:
-
Performance Analytics
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-15-2022 06:28 AM
Hello
If it is huge data it will slow down the instance while it runs the job to collect the data in the back end .We have faced this issue where PROD goes down for 30 minutes to 1 hour every morning as historical PA jobs will be blocking the session resulting slow ness.
Either you add queries to filter down the records so that at least it would stop the slowness and keep the session active for the end users in PROD
OR
Add filters to your indicator source and automated indicators and also create your own custom PA job with same configuration as the OOB one Reason being that for OOB jobs will have many indicators tagged from other PA reports and it will take time to collect the data for every report and then come to your report to collect the data and process it and display it on the PA widget. So if the record count is huge create your Own job. This helped us in our project to over come the slow ness
And another suggestion schedule the job at ODD times when people don't use PROD so that even if there is some slowness it might collect data after some time so that when users login they wont experience any slowness as the PA job would have already collected data
Please mark my answer correct if it helped you understand
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-15-2022 06:28 AM
Hello
If it is huge data it will slow down the instance while it runs the job to collect the data in the back end .We have faced this issue where PROD goes down for 30 minutes to 1 hour every morning as historical PA jobs will be blocking the session resulting slow ness.
Either you add queries to filter down the records so that at least it would stop the slowness and keep the session active for the end users in PROD
OR
Add filters to your indicator source and automated indicators and also create your own custom PA job with same configuration as the OOB one Reason being that for OOB jobs will have many indicators tagged from other PA reports and it will take time to collect the data for every report and then come to your report to collect the data and process it and display it on the PA widget. So if the record count is huge create your Own job. This helped us in our project to over come the slow ness
And another suggestion schedule the job at ODD times when people don't use PROD so that even if there is some slowness it might collect data after some time so that when users login they wont experience any slowness as the PA job would have already collected data
Please mark my answer correct if it helped you understand
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-15-2022 12:50 PM
Thanks, Mohith,
I think this first suggestion is not possible, as we want to see all the records which is used by the Audit team as well.
on the second suggestion,
Add filters to your indicator source and automated indicators - Paul: we are adamant about having all active VI only. so, I cannot have any options.
and also create your own custom PA job with the same configuration as the OOB one Reason being that OOB jobs will have many indicators tagged from other PA reports and it will take time to collect the data for every report and then come to your report to collect the data and process it and display it on the PA widget. Paul: this looks like a good idea, I can create a similar source and run it. So this new source will better the slowness in case this is the demand way to run and agreed by clients?
however, do we really need to run the "historical job" every day? just asking, only the delta data will be added right by the "Daily" job right?
So if the record count is huge create your Own job. This helped us in our project to overcome the slowness
And another suggestion schedule the job at ODD times when people don't use PROD so that even if there is some slowness it might collect data after some time so that when users login they wont experience any slowness as the PA job would have already collected data - Paul: Yes, you are right, I am already doing this, Mohit!
PaulSylo
Kindly mark "helpful", if this helps, or Mark as "Accepted " if it solves your issues !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-15-2022 12:55 PM
hello
i think we can remove the historical job too because it will be covered in daily job as you said and there is better and good chance that if there are no long running historical jobs we might experience less slowness so you can go ahead with that.
we can use historical jobs specifically if you want to collect the data or scores for records which existed before PA was set up in instance. But if our report ison daily basis lets ignore it
But yeah have a custom job and that would do your work
please mark my answer correct if it helped you in understanding
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-15-2022 01:37 PM
Hi Mohith -
Sure, I will run the history job for the very first time and I will remove it later!
Thanks, Mohith for your support and help.
Regards,
Paul
PaulSylo
Kindly mark "helpful", if this helps, or Mark as "Accepted " if it solves your issues !