AF SDK concurrency question

First, let's start with some background reading. This link is the granddaddy of them all regarding:

AF SDK performance, serial vs. parallel vs. bulk

Next, I would strongly emphasize that you should not try to change the PI Tuning parameters to make your app seem faster. I adhere to the philosophy that the PI Server is tuned the way it is for a reason and that I need to adjust my app to work with that PI Server as it is, and not the other way around.

Other guidelines of my philosophy:

• Do NOT overwhelm a server with my app since it may choke out other users or more importantly, other data collection services.
• Prefer Bulk over Per Tag Calls.
• Where justified, consider parallel or parallel + Bulk calls.

There was a presentation at vCampus Live! in the early 2010's. For parallel calls, the main thought it to take advantage of "transit time" aka network latency. It takes time for you to send a remote request and to get a response back. You want to keep the client busy almost constantly processing data coming back, and not to be idle waiting on transit time.

With that in mind, and that you do not want to choke out a PI Server, the thought is to use a MaxDegreeOfParallelism of 3 for PI Servers. That relates to fetching of data.

One good thing about parallel calls is that it can potentially improve the performance of your app. One bad thing about parallel calls is that it can potentially degrade the performance of your app. It all boils down to what the app is doing and how you issue parallel calls.

There are just so many factors specific to your PI environment and your app that it is hard to give a one-size-fits-all answer. Some users may have 1 million tags that have 24 readings per tag per day. Another user may have 10K tags that have 84K readings per tag per day (i.e. every second). Yet another user may have a mix of sparse data versus dense data, and this user is the most problematic.

Thank you for your response.

We do use parallel requests, so I don't believe transit time is the primary limitation here.

Unfortunately, we are unable to make bulk requests at the moment, as it would require architectural changes in multiple modules of the enterprise application. However, we will consider this in a future version.

What is the reasoning behind setting MaxDegreeOfParallelism to 3? Is it solely based on my experimental results, or is there a different rationale behind it?

(Q) What is the reasoning behind setting MaxDegreeOfParallelism to 3? 

(A) This was explicitly discussed in my previous answer but let me repeat: you do NOT want to overwhelm the PI Server with so many requests that it chokes out all other services or users. The value of 3 has been an OSIsoft recommendation for over a decade.

Bulk is by far and away the fastest way to retrieve data for lots of PI tags. If you cannot use bulk, then all the other heroic coding efforts will fall short on performance or else cause your data archive to automatically down-throttle because your app has greedily overwhelmed it with too many requests.

Good luck.

(Q) What is the reasoning behind setting MaxDegreeOfParallelism to 3? 

(A) This was explicitly discussed in my previous answer but let me repeat: you do NOT want to overwhelm the PI Server with so many requests that it chokes out all other services or users. The value of 3 has been an OSIsoft recommendation for over a decade.

Bulk is by far and away the fastest way to retrieve data for lots of PI tags. If you cannot use bulk, then all the other heroic coding efforts will fall short on performance or else cause your data archive to automatically down-throttle because your app has greedily overwhelmed it with too many requests.

Good luck.