Slow performance of AFAttribute.GetValues()

Discussion created by AlistairFrith on Oct 4, 2013
Latest reply on Dec 9, 2013 by Gregor

We have developed an application that, among other things, provides various historical summaries of potentially large numbers (tens of thousands) of AF Attributes belonging to large numbers (thousands) of elements. One of these reports is intended to run daily, during the early hours of the morning but sadly it takes up to 12 hours to complete! I have added some performance logging and narrowed the suspects down to this function: 

        /// <summary>
        /// Retrieve values for the specified AF Attribute over the specified time period from AF
        /// </summary>
        /// <param name="attribute"></param>
        /// <param name="timeRange"></param>
        /// <returns></returns>
        protected PIValues GetAttributeValues(AFAttribute attribute, ref AFTimeRange timeRange)

            PIValues piValues = attribute.GetValues(timeRange, 0, null).ToPIValues() as PIValues;

            return piValues;

When the report ran last night, the GetValues() call took on average 343.5 milliseconds but unfortunately, it had to be called 120,245 times! This means we spent 11.5 hours getting values from PI. The rest of the report code took a further 1/2 hour so anything I can do to reduce the time spent in GetValues() would be of huge benefit. A few things spring to mind:

  1. Is there any way to batch up a number of calls and send them as one? This would need a bit of structural redesign but might be worth it if the facility exists.
  2. The report mechanism is single-threaded. I could maybe try creating a separate thread per asset to allow these calls to run in parallel, but again, that would entail a fair bit of redesign.
  3. I will obviously try to see if I really need that many calls! There may be some repitition hiding in there but they do have 14,000 assets to report on and several data streams per asset.
  4. This is running on a system with AF SDK and AF Server AF is talking to a PI Server running 3.4.370 on fairly old hardware. They have had new hardware waiting for a PI Server migration and upgrade since before PI2012 came out but they have still not got around to doing it. I could imagine that the problem might just 'go away' if they just upgraded.
  5. Is it possible that network security and virus checking might be slowing down communication between the PI and AF servers?
  6. The attributes being analysed are actually using a custom AF reference that gets PI data and then queries a SQL database to find and apply adjustments to that data. I will try running it on standard PIPoint attributes to see if that is significantly faster.

Any comments or advice on this problem would be hugely appreciated.


--- Alistair.