Performance Analytics - Jobs related questions

PaulSylo
Tera Sage
Tera Sage

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

 

Regards,
PaulSylo

Kindly mark "helpful", if this helps, or Mark as "Accepted " if it solves your issues !
1 ACCEPTED SOLUTION

Mohith Devatte
Tera Sage
Tera Sage

Hello  @Paul Sylo ,

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 

 

View solution in original post

5 REPLIES 5

Mohith Devatte
Tera Sage
Tera Sage

Hello  @Paul Sylo ,

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 

 

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!

Regards,
PaulSylo

Kindly mark "helpful", if this helps, or Mark as "Accepted " if it solves your issues !

hello @Paul Sylo

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 @Paul Sylo 

 

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

Regards,
PaulSylo

Kindly mark "helpful", if this helps, or Mark as "Accepted " if it solves your issues !