10 Replies Latest reply on Jul 6, 2011 8:34 PM by spilon

    Performance of PI Web Services versus PI to PI Interface in pull configuration


      Hello Team,


      I have an external customer that would like data in my PI Server. They have a PI Server, but would like to use PI Web Services to pull the data if possible. I have read in another thread that Stephen Mohr is currently researching performance with PI Web Services, and that  "The number of events should be in the low tens of thousands" This is quite generic, and I'm sure depends on lots of factors, so can we examine my situation?


      PI Server 2010 in Seatle, WA. PI Web Services node in the same data center. Client Web Service is in Germany. Ping time is 318ms, windows file sharing yields a throughput of 193 KBytes/sec. I have 1000 float32 tags, each recieving 1 data point/second. 60,000 events/minute. Would it be possible to pull this amount of data using PI Web Services? I can do this with PI to PI and can keep the data up to date within a few seconds - using a push configuration for snapshot data through the Buffer. What overhead is involved with PI Web Services with this type of network communication? I know with the general PI Network Manager we send data in 4KB packets, and there is some overhead using the buffer, is there any compression/addtional overhead with PI Web Services?


      I am prepared to test this scenario, but would like some guidance on the approach. My plan is to use the Web Client in Germany to execute an asynchronous call using PIAsynchStatus for each of the 1000 points every minute. I am going to use the  basicHttp binding for the best performance. Are there any other performance tweaks I should consider?


      I would like to see if the limit is based on ping time and bandwidth. Even if I cannot send all of the data, I would like to know how much data I can send. I have done similar performance testing with the PI to PI Interface, and would like to see what PI Web Services can handle.




      Mike Jarvis

        • Re: Performance of PI Web Services versus PI to PI Interface in pull configuration

          Hi Mike,  My opinion...when it comes to data replication amongst PI servers then PItoPI is the choice of interface - sometimes there are questions over it's WAN performance but it is PI API based.  With PI Web Services you are introducing a translation element to the process.


          Are you looking for real time replication or happy with 1 minute gaps being filled in every minute?

            • Re: Performance of PI Web Services versus PI to PI Interface in pull configuration

              I am OK with having data with 1 minute gaps, I am actually OK with having data that is up to 10 minutes late. What I am trying to determine, is when a customer asks for data via PI Web Services, at what point can I tell them we have to use PI to PI (and force them to buy a PI Server)?

                • Re: Performance of PI Web Services versus PI to PI Interface in pull configuration

                  OK, I see.  I saw you mentioned this client had a PI server hence my point towards PItoPI.  From a more general perspective of data access to clients without a PI server, then yeah something like PI Web Services would be a good fit.  I'm sure Steve P. and others are hovering with some statistics to help in your quest for PI Web Services performance data.

                    • Re: Performance of PI Web Services versus PI to PI Interface in pull configuration

                      Hi Mike,


                      In your test scenario is the PI Web Services installed on a Web Server that is in Seattle (close to the PI Server) or close to the client that is consuming the data from PI Web Services? The deployment postion of PI Web Services should affect the throughput as well, because the traffic between PI Web Services is PI SDK traffic while between the PI Web Services and web client is HTTP traffic


                      I think the ideal situation is that the PI Web Services is running close to the PI Server and providing data to the web client. The main reason for this is to minimize the network latency between PI Web Services and PI Server so that the PI SDK connection between PI Web Services and PI Server can perform better.


                      Michael Jarvis

                      My plan is to use the Web Client in Germany to execute an asynchronous call using PIAsynchStatus for each of the 1000 points every minute

                      Need some clarification here. PIAsynchStatus is a PI SDK object, you probably don't need to deal with this if you are getting data from PI Web Services. Are you also deploying PI SDK in your client?


                      Personally I would be interested to know what metric you are intending to measure in this test scenario, as reading data through PI Web Services on a web client and data replication using PI to PI to another PI Server are 2 very different tasks. It would seem like the objective of this is really to determine whether or not the customer should replicate data to a local PI Server instead of a performance comparison between PI Web Services and PI to PI.


                      I would propose an alternative scenario to have PI Web Services and PI Server 2010 setup in Seattle and Germany. And compare the performance of reading data using through PI Web Services from both servers. That way we can compare the response time of reading the same data, same channel and leaving the only variable which is the geographical location of the servers (hence the difference in network condition). 


                      This ways it would be more apparent to the customer whether it is worth having PI to PI and an additional PI Server for the data replication to local site.


                      Hope this makes sense to you.

                • Re: Performance of PI Web Services versus PI to PI Interface in pull configuration

                  Hi Mike --


                  We've done some performance testing for a very specific use case, but some technical points came out of that which are applicable in your case.


                  First, if the WAN bandwidth supports it (XML is verbose), PI Web Services can easily handle the data rates you are talking about.  This is true even for the default wsHttpBinding you get when you install.


                  Next, the biggest issue related to performance is network latency.  The second biggest is security.  Assuming you don't want to shut off security on the WAN (unless this is a VPN secured by other means), you can get a surprising boost in performance by running multiple, concurrent clients.  So, for example, you could have ten WS clients, each taking 100 tags each minute.  In our testing, IIS easily handled concurrent clients, and PI didn't even notice, let alone break a sweat.  All the serializing/deserializing/network transmission can proceed in parallel, giving you substantial overlap.  Incidently, the next release of PI Web Services will push asynchronous processing much farther down in the stack for greater performance in this kind of situation.


                  The question of inserting the data on the other end is another matter, however.  Our InsertPIData call is orders of magnitude slower than our retrieval methods, which we want to address in a future release.  The client receiving the data on the far end should probably use the SDK directly to do the insertions.


                  In summary:

                  • you can get the data retrieval rates you want unless the WAN is too slow
                  • turn off security when it is feasible to do so -- wsHttp makes a bunch of round trips for this
                  • keep the WS as close to the originating PI Server as possible
                  • if you need to boost performance, run concurrent client instances