4 Replies Latest reply on Feb 5, 2013 11:37 PM by skwan

    PI Notification Real-Time


      While testing out the xml channel for PI Notifications, I am observing a lag in the trigger for periodic where I set the time period for 5 seconds. I am seeing delays of > 30 seconds in some instances. Even in the email notifications, the trigger value will be below the trheshold which causes some concern from my customers. I am not observing any strain on the servers so I do not believe I am overloaded.


      My questions are:


      1) Is there a limitation on the scheduler response? Is there a way to capture the exact time and value that triggered the notification. I want to use the XML channel to process events and I need to know the exact time the event was trigered and the value that triggered it.


      2) Is there a max number of notifications that a scheduler can handle? I have about 170 right now and need to add about 400 more. Would it help to break this up? Also, I always keep the "begin at time" at 00:00. Is this an offset that I should stag?


      Thank You,

        • Re: PI Notification Real-Time

          @Mike: I would start by saying that PI Notifications cannot be considered as a replacement of an alarm system. Even if its performance can be very high, more than 320,000 events per minute, the results can vary through time. Mainly this is due to the fact that there is also no guarantee that the PI System will deliver the events in time.


          This KB article can help to get the most out of your PI Notifications configuration. It also says that during our benchmark testing, we could successfully utilize a configuration that evaluates 10,000 notifications that generates 320,000 events per minute.


          To answer your first question, the notification instance start time uses the time of one of the defined triggers. To see the value that has triggered this instance, you simply need to insert the attribute as the content of the notification.


          The second answer is yes there is a maximum number but it depends of many factors. The numbers you describe are not very high for now. Although, several other factors may influence the speed of the delivery channel such as: network latency, IOPS, type of hard drive, operating system, etc. PI Notifications allows distributing the load across multiple schedulers; this is generally done with several hundreds of thousands of them.


          I would like to go back to the use case for real-time PI Notifications. Could you explain more to us on what you are trying to achieve.

            • Re: PI Notification Real-Time

              Thanks Mathieu


              Actually I am looking at notifications to be a "stand in" for Abacus, until is is ready. I need to capture events so I plan to using the XML message channel to capture when a process value is out of the min/max ranges. The min/max values and the process value are stored in AF attributes. I will either write these results to a database table and/or create event frames from these results. Right now, EFGEN is only available with PI points and not AF attributes(unless they derive from a PI point). I would like to use PI notifications to provide the analytics and generate messages when a value is too high, too low, or when it is OK. I will turn these messages into events. I am hoping that Abacus does come along, I can migrate over pretty simply.


              Any thoughts on that architecture is greatly welcomed


              Thank You,

                • Re: PI Notification Real-Time
                  Mike Zboray

                  For the trigger time and values, you can get the trigger time from the AFNotificationContentResults in the delivery channel's send method. Also you can get the attribute values for inputs if you have added them as content on the notification.


                  With regards to PI Notifications performance, there are a few things to keep in mind. One is that data access is very often a slow step. This is consistent with the fact that you are not seeing strain on the Notifications server and you see similar response times with both Email and XML delivery channels. Staggering the offsets for the periodic time rule usually only helps when you see spiking in CPU or memory and many notifications are on the same periodic schedule.


                  In the current notifications architecture there is one thread monitoring the time rules and evaluating the notification rules. It loops through all running notifications, checks if there are new events from the time rule, and executes the notification rules using the time context defined by the event. This means that all time rule events are not processed in a purely chronological order. For a given notification, events will be processed chronologically but this is not true in general. This means that if you have input attributes that are slow on one notification it may cause lag in the evaluation of time rule events for other notifications.


                  If you have the latest version of notifications then every 8 hours some statistics are printed to the pisdk log on what notification are taking the longest to evaluate. You might try checking there for any notifications that might be slowing everything else down. Try searching for messages over the past day for "Top analyses by average processing time". These are printed at the Information trace level from the PIAnalyticsProcessor so you should make sure that tracing level is on (it is by default).

                    • Re: PI Notification Real-Time



                      We currently do not have a plan to provide a tool to migrate PI Notifications over to Abacus.  However, given that PI Notifications and Abacus expressions have a lot of similariities, without actually seeing your expression(s), I wouldn't be surprised that you can "copy/paste" between the two.  Having said that, we may consider a migration tool both for regular PE's in the PI Server and also PI Notifications in the future.