MGendron

Performance tests in getting EventFrames

Discussion created by MGendron on Sep 2, 2011
Latest reply on Sep 17, 2012 by williamsd

Hi VCampus!

 

I'm new to the AF SDK and am currently reviewing the performance of the EventFrame functionality. We want to know how fast EventFrame's fetching functions are and if they are a viable option for quick reporting. We need to know if it's at least as fast as the next PI OLEDB release, otherwise we'll just use SQL queries through OLEDB.

 

We wrote a test program to benchmark all the "find" methods of the EventFrame namespace. Each method is called between two Date.Now and we calculate the resulting timespan. We work with 40000 EventFrames spread across 20000 minutes before the 2011-09-01. Each EventFrame come from a template and has 2 attributes, a double and a string, each indexed. Each double attribute was set a random value between 0 to 1000 and each string attribute was set a random string between "Code1" to "Code10".

 

So here's the results:

  • AFEventFrame.FindEventFrames: 40002 frames in 8 secs, 846 millis
  • AFEventFrame.FindEventFramesByAttribute (String attribute matching "Code2" or "Code3"): 8034 frames in 2 secs, 656 millis
  • AFAttribute.FindEventFrameAttributes: 40002 frames in 2 mins, 51 secs, 611 millis. Filling a listbox with the double attribute values from the resulting collection: 6 secs, 862 millis
  • Getting the EventFrame count grouped by "Code" with a SQL query: about 1 secs

We have 2 problems with these results:

  1. The difference between the FindEventFrames and FindEventFrameAttributes is that one preload all the values right away. If you want to use an attribute value from every EventFrame returned, you end up with the same time, around 3 minutes, which is way too long for creating a report.
  2. If we only want to count the numbers of EventFrame per "Code" (the values of the string attribute) then the FindEventFramesByAttribute works ok (2.5 secs). But you would have to use the method for each known "Code", multiplying the required time. And you need to know the possible values in advance.

In both case, a SQL query against AF tables is a much faster option. So what do you think? Is there a method or parameter in the AF SDK I missed? Will the performance be improved? Or am I trying something that EventFrames are not meant to do? Will the performance of the incoming PI OLEDB for EventFrame be comparable to working directly with SQL?

Outcomes