8 Replies Latest reply on Jan 18, 2018 3:55 AM by dhollebeek

    Performance Measurement for Processbook and Datalink


      Dear All!


      We always / sometimes got complains from our users that the preformance of the pi system doesn't meet their expectated values.


      After watching this TED Talk (http://www.ted.com/talks/rory_sutherland_perspective_is_everything.html) it comes to my mind maybe i can present the users some numbers:


      For example:

      • 90 % of the processbooks are open below 3 seconds.
      • 90 % of the datalink enabled function are open (and calculated below 5 seconds)

      I'm aware of the reasons for long opening times can be multilayered.

      • it can be the compression of the datapoints below (that the reason most suggested on osisoft .. if you have a perfomance problem increase the compression)
      • it can be that  hardware isn't delivery the performace (we use SSD for the last 100 days of data,.. and with PI2012 i hope this improves)
      • it can be that in processbooks and calculation the intervall is too narrow (1 minutes caluclations for 3 years..)
      • it can be that in datalink the data gathering is not performaned the ideal way,..
      • it can be that the users has no rights to the data and for this the timeout takes too long (seen a couple of times)
      • ....

      and if you sit down on a beer with me .. in can think of sure a couple of more reasons:


      What i wanted to to is to get real performance data:

      • how long does it take to open processsbook displays, excel reports.
      • are their some displays, reports which takes more time the we expect (5 seconds,...)

      So the idea is to develop a plugin for processbook and excel which reports the calculation time / opening time for each file with a distinct user.


      Logging this information in  sql database isn't the issue, but how do i measure this data in processbook or excel ?







        • Re: Performance Measurement for Processbook and Datalink

          We actually do this testing internally with a list of displays.  I'm not sure exactly how the tests run, but I think we mainly measure the time between us calling VBA to open the display and when the display.open or display.activate or display.dataupdate events fire.

            • Re: Performance Measurement for Processbook and Datalink

              Some of the time to open displays may vary based on the version of PI ProcessBook and the vintage of the display. For example, in the latest release, we've done some work to more unambiguously determine whether a data item is a PI Tag, a dataset, an AF reference, etc. and once that data is captured in the display, it opens much faster than before. Unfortunately, that enhancement comes at a bit of a cost the first time you open a display created in an earlier version (where that information on data source needs to be determined and saved in the display).


              Hopefully, Dave's suggestions above will be of use in your quest, Wolfgang. :-)

                • Re: Performance Measurement for Processbook and Datalink

                  Also, if you have any displays that seem to open unacceptably slowly (for no discernable reason), feel free to send them to us via tech support and we can incorporate a similar display into our testing.


                  As far as PB2012 goes, make sure to resave the files in the 2012 format, which should cause them to open somewhat faster.



                    • Re: Performance Measurement for Processbook and Datalink

                      If develop an addin, then as well as the opening times you may want to capture some statistics about displays.  Number of symbols, broken data links, ...  same as the Display's Status information.  Then check for the presence of VBA for key events, like Display_Open.  Log the VBA so if there is unusually long opening times, it may be some unintentional VBA overhead and not ProcessBook itself.  Seen that all too often.


                      Many moons ago I had some VBA to track most frequently accessed displays from a library of displays so that the more popular displays we're more optimised than others - there were hundreds of displays so hard to optimise them all.

                        • Re: Performance Measurement for Processbook and Datalink

                          ... but what are the two relevant events .... Display_Open and which one tells me that all data is gathared and the calculations are done...

                            • Re: Performance Measurement for Processbook and Datalink



                              IIRC, Display_DataUpdate fires after all the symbols have gotten their initial data.



                                • Re: Performance Measurement for Processbook and Datalink

                                  I know this is a very old thread, but I was trying to use the above information to test startup performance of processbook displays.

                                  However, I'm not sure how I can add an event listener to a Display object to listen for the DataUpdate event.


                                  This is in the assumption that one processbook display file (A) opens a list of other PIW/PDI files and (A) waits for the DataUpdate event of the opened display to fire.



                                  Dim disp As PBObjLib.Display

                                  Set disp = Application.Displays.Open("C:\test.PDI", True)


                                  Is there a way to set a handler for the  Activated, Open or DataUpdate events from the calling code?

                                  Or is it better to add event handlers to each of the displays to be measured and log the timestamps to a common logfile? This way I would have to modify all the displays in the test set, which is what I am trying to avoid.

                                    • Re: Performance Measurement for Processbook and Datalink

                                      In their simplest form, event handlers are called in the display that caused them.  I.e. in this case, a DataUpdate event is fired in the VBA code in every open display when ProcessBook updates the data (that way each display can handle it differently.  It is possible to do what you are saying where one display listens to events from another display, but in most cases that is ufnecessarily complicated.  If you get to the point where you have one set of code managing multiple displays, you are probably better off writing a custom add-in.




                                      2 of 2 people found this helpful