3 of 3 people found this helpful
Latency and application performance are a little tricky to calculate as they are dependent on a lot of factors including the specifications and architecture (w.r.t each other) of the client, AF & PI data archive.
RPC metrics for AFSDK (>=2.9) custom code can be calculated using the OSIsoft.AF.Diagnostics
Refer to Using metrics in your AF SDK code
Data retrieval directly from the PI Archive: OSIsoft.AF.PI Namespace
The OSIsoft.AF.PI namespace provides a set of classes that can be used to manage connections and access information about a PI Data Archive.
Data retrieval through PI AF: AFData Class Namespace
The AFData object is associated with a single AFAttribute and is used to retrieve and set extended historical data. It is accessed through the Data property of an AFAttribute
For performance calculations, keep in mind the AFData Cache.
One would assume that pulling data through AF might have some inherent latency(due to some WCF overhead involved), but if this is not significant, it can be ignored for the other benefits offered by this method.
My suggestion would be to go with data retrieval through AF, as it is a single repository for asset-centric models, hierarchies, objects, and equipment. It integrates, contextualizes, and further analyzes data from multiple sources, including one or more PI Data Archives and non-PI sources such as external relational databases. Together, these metadata and time series data provide a detailed description of equipment or assets. Scalability of the code is also easily accomplished using AF. Using just the PI DA, would be accessing a collection of PI points without having the above mentioned benefits.
Thanks, that helps.
Goes along with what I was thinking as well, I just didn't have any research to back-up my assertions.
2 of 2 people found this helpful
By "pulling data out of AF", does this mean you have an AFDatabase defined and you want to interact with elements and attributes? Or do you merely want to pull data out of the PI Data Archive but use the PI AF SDK do to so?
I can speak as a former customer, and using PI AF SDK against the PI Data Archive was faster to execute than using PI SDK. And it was easier and quicker to develop in the AF SDK.
If you are working with an asset hierarchy, then my personal experience was that it was a bit slower finding and loading elements than to connect to the data archive and fetch PI points (not data yet). This is not always the case, as a staggering array of factors can make one faster than the other. And there are tricks to do partial loading of just the attributes you desire, as long as they do not have a dependency upon other attributes. But that is sometimes the case with a robust AFDatabase is the use of table lookups, relative attributes, and String Builder to compose the name of PI tags. Putting all of that aside, once you have a list of AFAttributes that use the PI Point data reference, then data retrieval of those attributes is almost as fast as if they were PI points. Why almost and not the same as? Because the PI points retrieve the data without regard to UOM but the attributes may have to convert to the desired UOM.