The PI Software Development Kit (PI SDK) is a programming library providing access to PI Servers. The product is primarily middleware in that it provides an interface between the PI Server back-end and end-user applications.
PI SDK communicates to the PI Server through the local PI-Network Manager (pinetmgr) which in turn opens a TCP\IP connection to the pinetmgr on the PI Server. The protocol that is used at the application layer is referred as PINET3.
One of the known inefficiencies in PI SDK, more specifically PINET3 put data in 4kb message blocks and an ACK message is sent for every 4kb message. This causes additional overhead, and causing PI SDK to perform badly especially in high-latency network.
Improvement in 3.4.380 PI Network Manager
The improvement of the PI Network Manager in 3.4.380 is mainly targeted at eliminate the known inefficiency. This makes the PI SDK client perform better with PI 3.4.380 compared to PI 3.4.375 and earlier versions. This can be tested by measuring the time taken for an SDK client to complete a call for data from the servers. For convenience in the rest of the blog post, I shall refer to the 3.4.380 PI Network Manager as "PINET380" whereas the older version shall be referred as "PINET375"
For testing, I created a very simple PI SDK program in Visual C# 2008 with PI-SDK 184.108.40.2064. The program is only intended to read archived data from a PI tag for a period of time. The specific SDK call is PISDK.PIPoint.PIData.RecordedValues().
A way to measure the time taken for the call is to measure the time before the call and after the call. Alternatively, we can perform PI SDK tracing to log the PI SDK connection and operations (see the "Troubleshooting" article in the PI SDK Programming Reference, available on the OSIsoft vCampus Library). We can set the debug level to "Wire Calls" or "Verbose" to see the time spend TCP/IP communicates for the call.
The parameters that are varied include
In terms of latency, I have simply varied it changing my connection setup, 1st by connecting to the servers through wireless LAN and also connecting to an external network and connecting to the servers via VPN, which drastically increases latency because traffic is routed to OSIsoft's San Leandro HQ before coming back to OSIsoft Singapore.
Number of Events
This is pretty straight-forward, the start and end time of the PI SDK call is adjusted to retrieve different amounts of data.
Running the test for a couple of times to get an average of response time, and here's the results that I have
When the network condition is good, with high bandwidth and low latency, we can see that reading from PINET380 has slight improvements in comparison to PINET375 but generally it is not significant to affect user's experiences.
When running test on a client connecting to the servers via VPN through wide area network
However if we look at the results in a situation where network has high latency (about 400 to 500 ms measure with PING), the results generally still shows that PINET380 performs better than PINET375. The difference would show if you are grabbing large amounts of data out at one shot.
When running test on client connects to servers through wide area network with high retransmission
Another situation that I managed to get is a case where the network is bad enough that a lot of retransmission traffic is observed using Wireshark. In this case, this is really where significant difference in performance is observed. Because of the overhead, PINET375 performs significantly slower compared to PINET380.
The results do show that there is a significant increase in the performance when we are in a situation with high latency. If you have a lot of users reading data from the PI Server via a high latency network, you probably find it helpful to upgrade the PI server for the performance improvement.
In closing, I still like to highlight the fact that we are still subjected to other factors that can cause performance to degrade, like server performance, client machine's load. Upgrading to the new PI Server should not be regarded as a move that guarantees improvement in performance in all cases.
One last thing to note is that even the latest PI SDK release 220.127.116.114 is packaged with PINET375. This means that any API node without PI server installed will only have PINET375. Any connection from a PINET375 node to PINET380 server will only enjoy the performance improvement when reading data from the server but not the other way round, until PINET380 is released with PI SDK.