8 of 8 people found this helpful
Your approach to using the PI Web API is not necessarily wrong. As a general rule, you will always get better performance when using the AFSDK natively, as opposed to using other technologies such as the PI Web API or the OLEDB providers. This is because technologies such as PI Web API have to translate the calls you make to it into SDK calls when it accesses the data archive server or the asset server, and then wraps the returned data into a JSON bundle to send back to the caller. You then add a little more overhead by having to deserialize that into a format you can use.
When deciding which development technology to use for your application, you need to consider multiple factors, performance being just one of them. Is the performance difference crucial to the requirements that your custom application is being built to address? If the answer is yes, then don't use the PI Web API. Will there be restrictions or limitations on your ability to deploy the PI AF Client package along with your application on the target machine(s)? If yes, the the PI Web API will allow you to run your custom application as a kind of thin client with no additional software needing to be installed. Will your application be required to run on non-Windows platforms? What additional requirements will you need to meet with your application? Remember also that the PI Web API is not a fully featured replacement for the AFSDK - there are some things you just can't do using the PI Web API at present (and that may not change in the future). Will some of your application features require functionality only available natively in the AFSDK?
I'm more of an SDK developer than a web API developer - most of the time using the SDK is a more appropriate choice in the applications I write. Plus I am more familiar with the SDK, so I stick with the familiar. While I've only recently begun exploring the PI Web API, so far the only reason I've had to use it has been to cover a cross-platform requirement for a specific custom application. And the performance difference was quite noticeable, but is a trade-off that had to be made for cross-platform compatibility.
So if there are no barriers to writing a native SDK application, then I would recommend that route as you will get a better performing application in terms of data access (you still have to use the appropriate bulk methods to realise many of these gains).
Thank you for your clarification - this strengthens our own conclusion to go with the SDK.
Performance is imperative for our solutions since we process and aggregate years of data from several tags at a time.
1 of 1 people found this helpful
If you are interested in performance of AF SDK applications when accessing large amounts of data you may be interested in the below documents comparing bulk, serial, and parallel calls:
Good luck with your pilot project.
I will look into those documents in the new year since I'm currently on christmas holliday.
Happy holidays all contributors!