3 Replies Latest reply on Mar 30, 2018 8:03 PM by sraposo

    In a set of Analysis Calculation Groups, what does (Rank:0) signify?


      I am working with an AF Analytics service with escalating scheduling lag issues.


      We've been tracing these lag issues through the various calculation groups running on the service, and have noticed that all of our worst-performing analyses are Naturally scheduled with the suffix "(Rank:0)" through to "(Rank:5)". 1) What precisely does Rank signify?


      My starting assumption was that these indicate dependencies upon other calculations, but then I've observed that my highest AverageLagms results are for Rank:0 calculations, and then sequentially Rank:1, Rank:2 etc each have lower worst-performers than the previous Rank. So it seems counterintuitive that if my few 5's are those with five layers of dependencies, that they would have the least lag accruing.


      In general we have already fixed our worst-performers which were making liberal use of expensive functions - most of these ones left in my list are legitimate calculations happening at (relatively) sensible natural intervals, and so I have reservations about putting them all to Fixed periods unnecessarily.


      Regardless of their cause, 2) Are there particular Analysis Service Configuration options which govern this Ranking behaviour and could help finetune the performance of these groups?


      Many thanks


        • Re: In a set of Analysis Calculation Groups, what does (Rank:0) signify?

          Hi Steven,


          Which version of Asset Analytics are you running? I'm asking as the statistic reporting as changed considerably over the years.


          Your assumption is correct, the rank signifies the level of dependency.


          In terms of lag, there are different types of lag, notably SchedulingLag and EvaluationLag. The AverageLagMilliSeconds you are seeing at the analysis level is a report of the EvaluationLag. When the analysis triggers it takes time for the evaluation to happen and this time is considered EvaluationLag.  The higher rank analyses might be performing better than the lower rank analyses and this is why the AverageMilliSeconds lag you are seeing is lower. If you have a look at the LastCompletedRequestStatistics for that analysis group, I suspect that you will see a high SchedulingLag. SchedulingLag reports the amount of time between when the analysis should have been triggered and when it was actually triggered. When lower rank analyses aren't performing well, they delay the execution of higher rank analyses or in other words they delay the scheduling of higher rank analyses.


          In terms of service configuration, there are none that govern the ranking behavior. That being said there are some configuration parameters that could be changed to better the performance of your analysis service in general.


          In 2018, there are significant enhancements done in terms of performance of dependent analyses. The release is due at the end of Q2 2018: https://techsupport.osisoft.com/Products/Product-Roadmap


          I hope this helps clear things up!




          • Re: In a set of Analysis Calculation Groups, what does (Rank:0) signify?

            Hi, Steven.

            One thing we've seen with lagging systems is that the slow analyses can be caused by inputs that are slow to resolve, especially inputs from linked table lookups to remote databases.  Are any of the analyses in your troublesome groups using these types of inputs?  I think you will find the following two KB articles to be helpful:

            Troubleshooting: Request Rejected

            Best practices: Request Rejected

            Please keep us posted on your findings.

            1 of 1 people found this helpful
              • Re: In a set of Analysis Calculation Groups, what does (Rank:0) signify?

                Thanks Brent Bregenzer for sharing those KBs!


                From my experience in support, typically poorly performing Asset Analytics system are a result of not following the best practices in the KB you shared.


                Just a small note, we are working on updating the best practice KB.


                Two important things to consider that we are adding are: the data density of the inputs and the data pattern.


                Of course if the input data is denser this will require a greater computational effort and will therefore be more resource intensive. It's extremely important to have properly set exception and compression settings in your PI Data Archive. More information can be found here: https://techsupport.osisoft.com/Troubleshooting/KB/3226OSI8/


                It's important that analyses are scheduled logically with the input data pattern or are scheduled on a need basis for the users. For example, if an input updates every 5s and the analysis only has 1 input, it doesn't make logical sense to have it running every 1s. Another example, if a calculation only needs to run once a day then it should be configured to only run once a day.


                Hope this helps,