13 Replies Latest reply on May 12, 2011 12:04 AM by charlie@osisoft.com

    Many small EventPipes vs. one large EventPipe

    ZevArnold

      Can you speak to the efficiency trade-offs between using a separate EventPipe for each tag and using a single EventPipe for all tags?  Assuming handling on my side isn't noticeably more complex either way, what issues may arise with one approach over the other?  Is one approach clearly more efficient?  Are there any relevant trade-offs in resources?

        • Re: Many small EventPipes vs. one large EventPipe
          jeffjamesmcmahon

          I am pretty interested in the OSIsoft opinions on this one too...  in the meantime i can report my own findings.

           

          1) Started out using an EventPipe Per Tag.  Testing up to about 100 tags showed no issues at all - all worked great.

           

          2) Requirements changed so that we needed to increase tag count to 10K - ran testing using one-to-one EP to Tag and experienced a dramatic slow down while creating the EventPipes past around 2000, let it run all night and still did not finish allocating them.

           

          3) Changed to using a single EventPipe on the PointList.  Re-ran testing - works perfectly.

           

          So, if your tag counts are small, based on my experience, you can use individual EP's.  Otherwise, use one.  Have not tested any combinations between 1-1 and 1-* (such as partitioning your tag space into groups and using a separate PointList::EventPipe for each group, but that would be an interesting experiment)

            • Re: Many small EventPipes vs. one large EventPipe

              I would definitely recommend using any PointList functionality you can (i.e. one EP for multiple tags). When such "bulk" objects/methods are implemented, it's usually because there was a good way to optimize these calls (i.e. less roundtrips to the server) and I would recommend using those.

               

              However I will have to let others comment on the "reasonable limit" of tags per Event Pipe, if such a limit exists.

                • Re: Many small EventPipes vs. one large EventPipe
                  ZevArnold

                  Steve and Jeff, thanks for your replies.

                   

                  A follow-up on the number of tags per Event Pipe, PI-PI is usually not recommended for more than 2500 to 5000 tags (depending on the version, etc..).  Is this because of the Event Pipe?  Has OSIsoft acknowledged an officially supported limit on EventPipes or does it officially support EventPipes of unlimited size?

                    • Re: Many small EventPipes vs. one large EventPipe

                      Do you have a reference for the pitopi recommendation(s)?  Currently I have multiple instances running around 25,000 tags each with archive recovery and it works very well (startup could be faster).

                        • Re: Many small EventPipes vs. one large EventPipe
                          ZevArnold

                          Rhys, I'm afraid I can't provide anything more concrete.  The comment comes from my recollection of discussions with OSIsoft tech support and some bizarre behavior I've noticed on PI-PI over the last few years.  However, for the record, 25k tags on a PI-PI interface would make me very nervous.  I usually limit it to 5k.

                            • Re: Many small EventPipes vs. one large EventPipe

                              If you saw the web of pitopi instances you would need some tablets for your nerves

                               

                              In all seriousness, so far the systems have been running good and performing well.  If OSI can't get data replication right for >5,000 data points in one interface we all have something to worry about. I'm trying very hard not to mention SSB...

                                • Re: Many small EventPipes vs. one large EventPipe

                                  Sorry Zev, realised I'm taking focus off your original event pipes question.  

                                   

                                  Someone give Charlie a nudge.

                                    • Re: Many small EventPipes vs. one large EventPipe
                                      Ahmad Fattahi

                                      Zev,

                                       

                                      As for the EP, the analogy is like sending one courier to collect 5000 mails, bring them in, and handle locally vs. sending the courier 5000 times to bring them in one at a time. The "post-handling" would take slightly LESS effort in the latter case but the round trip load would dominate. Therefore, using the optimized PointList features would be more efficient.

                                       

                                      As for the PItoPI interface, the concrete limit would depend (as usual) on many factors such as scan classes, number of events, network latency, and systems capacity. It is always advised to break down a collection of bulk points to a number of smaller groups so the load is spread out over time. The few thousand points per interface instance is something of a rule of thumb which would in reality depend on the above factors.

                                        • Re: Many small EventPipes vs. one large EventPipe
                                          ZevArnold

                                          Ahmad,  thanks for your reply.

                                           

                                          My point re: PI-PI was less about the specific limitations for PI-PI then officially supported limits for the EventPipe.  Given enough system memory and unlimited bandwidth and a PI server of god-like qualities, does OSIsoft officially support a single EventPipe being used for unlimited tags or is there an upper limit?

                                           

                                          Thanks,

                                            • Re: Many small EventPipes vs. one large EventPipe
                                              Ahmad Fattahi

                                              Well, the literal answer to your question is "yes". However, the problem is the conditions in your question are never met in real world. There are always limitations somewhere; if there were no limitations on anything we wouldn't have this conversation here . The point is that there is no concrete limit due to complexity of the factors involved. For a simple example of how complex things can get see this blog post where it shows even comparing two processors in terms of speed is far from trivial.

                                               

                                               

                                                • Re: Many small EventPipes vs. one large EventPipe

                                                  I can speak a bit to PItoPI's capacity - it was mine 12 years ago and back then I used to do 25k tags with PI 3.1!  I haven't used it for years, but I can get Paul W to comment if you want something more current.

                                                   

                                                  PItoPI does not use PISDK EventPipes.  It uses the PIAPI signup call which goes through the translator (hosted in pinetmgr).  By the time these calls get to the PI Update Manager, they look similar.

                                                   

                                                  The PI Update Manager has two relevant settings, the maximum queued events per signup, and the total queue for all signups.  These exist in order to prevent unbounded memory consumption.  Memory may be consumed when a client is abnormally disconnected, and the signups are stranded.  Eventually, the client's disconnection is detected and cleanup ensues.  However, in the interim, the events keep queueing.  The limits on old servers used to be 5000/100000 events, but those are much higher now (just checked - 10* that now by default).  Besides, only lazy clients don't process their events;)  Oh yes, the PISDK EventPipe is able to find any stranded queues of data upon reconnection if the client application continues running and reconnects before the server cleans up.  Hopefully that explains the server side a bit.

                                                   

                                                  For the client side, I typically recommend that the PointList be separated into <100k PIPoints, though your site may need less because of loads.  However, if you have many events/seconds, you may need to go substantially lower.  So the limitation in the PISDK is not so much the number of signups, but the event rate.  I would not expect beyond a few thousand events/second for an EventPipe.  You may need to spawn many threads, each with their own list.  However, there is a bottleneck in the PISDK and its elimination has not made it onto the short list.

                                                   

                                                  Hi Rhys, I noticed the pile-up of notifications, but was deep into solving a problem (it turned out to be a bad test program if you're interested - and maybe turning off the OS debug settings for UST!).