Welcome to Part 2 of a 3-part series on creating a Duration attribute on an event frame.

 

Part 1 - How To using StringBuilder DR for Start and End Time attributes

Part 2 - Performance Testing, Methodology, and Results

Part 3 - Variations on a Theme

 

Creating a Performance Test

It wasn't difficult to come up with a simple test of a simple application: essentially create a bunch of event frames, and later try to read data from the Duration attribute.  Since this test was run repeatedly, it also deleted existing event frames and while I measured the deletion time out of curiosity, it was not a required metric.  Along the way, I quickly discovered there is no bulk delete for event frames, i.e. it took a long time to delete 100,000 event frames, so I quickly scaled back to test 10,000 event frames out of the sincerely held belief that life is too short.

 

The event frames started at 1 minute duration, followed by a gap in with the same duration, and then increased by 1 minute up to 2 hours until all 10,000 event frames were created.  This process looked something like:

 

Event frame 1 minute duration, followed by 1 minute gap before the next frame.

Event frame 2 minute duration, followed by 2 minute gap before the next frame.

Event frame 3 minute duration, followed by 3 minute gap before the next frame.

{ repeat process adding 1 minute each time, until you reach 120 minutes}

Event frame 118 minute duration, followed by 118 minute gap before the next frame.

Event frame 119 minute duration, followed by 119 minute gap before the next frame.

Event frame 120 minute duration, followed by 120 minute gap before the next frame.

{ repeat process subtracting 1 minute each time, until you reach 1 minute}

Event frame 119 minute duration, followed by 119 minute gap before the next frame.

Event frame 118 minute duration, followed by 118 minute gap before the next frame.

{ repeat entire loop until 10,000 event frames are created}

 

Methods Tested

Three different methods were tested:

 

  1. Older method of using a PIPoint.  Since the tag is called "Sinusoid", I nicknamed this test "Sinusoid".
  2. Using StringBuilder DR as mentioned in Part 1.  I nicknamed this "StringBuilder".
  3. A variation on StringBuilder to be discussed in Part 3, appropriately nicknamed "Part 3".

 

I ran the test 3 times for a given environment, rotating the order of each method to be tested.  I learned many years ago that when testing PI performance you really need to alter the order of comparisons to make sure that caching doesn't skew the results.

 

Local Results

The first round of tests were all isolated to one laptop.  The Data Archive, Asset Server, SQL Server, and test app all ran from one dual core laptop with 2.6 Ghz CPU and 8 GB RAM.

 

     Values displayed are in elapsed seconds for all 10,000 event frames.

Results 1 Local.png

 

Creating event frames, checking them in, and later retrieving them again all took about the same time.  You will note a big jump when reading values for the Sinusoid.

 

LAN Results

The second round of tests moved the test application to a 4 core desktop with 3.4 Ghz CPU and 16 GB RAM.  The Data Archive, Asset Server, and SQL Server still run on the dual core laptop with 2.6 Ghz CPU and 8 GB RAM.  Both machines are connected to a 100 Mbps switch.

 

     Values displayed are in elapsed seconds for all 10,000 event frames.

Results 2 LAN.png

 

As we are making a short trip across LAN, the time for Sinusoid jumped up almost 75%.  The other methods tested were faster, but again that reflects the faster CPU's on the desktop hosting the test application.

 

Creating and check-in increased slightly from the Local tests, though retrieving the event frames was about the same.

 

WAN Results

The third round of tests moved the test application back to the 2 core laptop as in the Local tests.  The Asset Server, SQL Server, and test app still run on the 2 core laptop.  However, the Data Archive is a PI Server 1900 miles (3060 kilometers) across country.  All that is referenced from the Data Archive will be the Sinusoid PIPoint. 

 

     Values displayed are in elapsed seconds for all 10,000 event frames.

Results 3 WAN.png

 

Are further comments really needed at this point?  I can't find the words to better illustrate the difference already aptly shown in the graphic above.

 

The "Cost" of StringBuilder

There is no performance cost to using StringBuilder to create the Start and End Times.  The only real "cost" is creating what many feel to be redundant attributes that mirror existing properties already on the event frame.  Given the performance benefit of using StringBuilder, I will happily live with that redundancy.

 

Next up in the series, we finish up by talking about this mysterious 3rd method tested.