4 Replies Latest reply on Dec 13, 2016 8:21 AM by Dries.Verhees

    Performance RecordedValue unsatisfying


      Dear all,


      I am optimizing the performance of my application and I noticed that almost all the time is spent in an AF SDK call.

      In order to investigate it further, I have implemented a console application.


      The console application first selects the AF attributes:


      AFSearchToken elnToken = new AFSearchToken(AFSearchFilter.Name, AFSearchOperator.Equal, "RT_Data");

      AFElementSearch search = new AFElementSearch(afDatabase, "", new List<AFSearchToken> { elnToken });

      var elements = search.FindElements();

      var attributeList = new AFAttributeList();

      foreach (var element in elements)


            var attribute = element.Attributes["Oil Rate"];



      Console.WriteLine($"{attributeList.Count} attributes selected");


      This is working fine and fast. There are 18 attributes selected. All these attributes are configured as PI Point on the same PI server. For some of the attributes, the tag does not exist on the PI server.


      Once I have the list available, I request one raw value per attribute.


      AFTime afTime = new AFTime(DateTime.Now.Date.ToUniversalTime());

      Console.WriteLine($"Time: {afTime.LocalTime}");

      Stopwatch stopWatch = Stopwatch.StartNew();

      var data = attributeList.Data.RecordedValue(afTime, AFRetrievalMode.AtOrBefore);


      Console.WriteLine($"Elapsed time: {stopWatch.Elapsed.TotalMilliseconds} ms ({data.Count} values)");



      The first data call takes about 10 seconds. The next calls are taken about 1 - 5 seconds. (only attributeList.Data.RecordedValue is measured)


      I am using the following versions:

      • AF SDK:
      • AF server:
      • PI server: 3.4.405.1198


      I have the feeling that 10 seconds (and even 4 seconds) is unacceptable for only 18 recent data points, but I am trying to find the cause.

      Can anyone point me in the right direction?




        • Re: Performance RecordedValue unsatisfying
          Roger Palmen

          Should be quick enough, i don't see any obvious issues. Last time i did this was for 600K data points in mere seconds.


          If you request the same data e.g. using PSE on the same client, what is the performance? Same or faster?

          • Re: Performance RecordedValue unsatisfying

            Hello Dries,


            There are several factor that may influence your application performances. I'll try to explain the most relevant ones in your situation.



            With you code, the PI AF SDK will need to perform 2 connections one for AF and the other one for the PI Data Archive. You seem to face a situation where your PI data Archive connection takes 5 seconds. The network and the name resolution (because our connection mechanism uses reverse lookup - see Troubleshooting PI client connection problems p.12 for more info ) may impact the time it takes to make the connection.  However, after the connection is established for the first time, the PI AF SDK will cache the connection based on your windows user and the running process so the next time your application performs a data call there will be no delay. And because the process of a console applications terminates after each execution each time you run the app you have to wait again for the connection.


            A 5 to 10s connection time is normal, the connection process involves a lot of tasks such as Reverse Lookup and Authentication and is expensive to do.  Once connection is established you should not call disconnect explicitly.  The next time your code will run it will use the existing connection.


            Data Call

            The 1-5s duration seems a bit on the high side.  Is your PI Data Archive busy or far away? Is your network busy? This might explain.

            Other than that the bulk calls mechanism ( when using an attribute list like you are doing) also involves some overhead.  It is a very good technique to fight against latency but as you don't have very much attributes you may try a simple loop and call the RecordedValue method from each attribute instead e.g. attribute.Data.RecordedValue(...) ( See AFData).


            Hope this gives you a starting point.

            Also, if you could explain us what you need to achieve, what tasks and what performances you are after we can probably help you defining a design for your application.  Please let us know!

            1 of 1 people found this helpful
            • Re: Performance RecordedValue unsatisfying
              Rick Davin

              Hi Dries,


              You said:


              This is working fine and fast. There are 18 attributes selected. All these attributes are configured as PI Point on the same PI server. For some of the attributes, the tag does not exist on the PI server.


              What stands out to me is:  For some of the attributes, the tag does not exist on the PI server.


              My past experience is that bulk calls where some PIPoints don't exist can be a performance drag.  Is there anyway you can remove the attributes with non-existent PIPoints or else create the PIPoints where needed?


              If you wanted to experiment with more stopwatch timings, could issue split out your code to have an AFAttributeList.GetPIPoint call.  That call alone might be consuming the most time.  With the results from the GetPIPoint, you would then filter out any where the returned PIPoint is null.  That would leave with attributes that have a valid PIPoint.  Once you have that, then use a stopwatch around the RecordedValue call again.

              2 of 2 people found this helpful
              • Re: Performance RecordedValue unsatisfying

                Hi all,


                Thank you for the input. I am still testing a couple of scenarios.


                Since the AF was running on an old machine, I have installed the latest AF server on a new machine. The performance is better, but not satisfying.
                The first call takes about 8.5 seconds. If the second call is executed within 20 seconds, it takes only 20ms. If I wait for a couple of minutes, the next call takes about 3 seconds.

                The Pi server is a recent server with not many tags. All servers are in the same network, physically next to each other, including the client. But it could also be related to a slow reverse lookup.


                As a next test, I will investigate whether the missing PI points will have an effect on the timings.



                I will keep you updated, thank you all for the steer.