We are experiencing slowness when loading PI ICU on remote interface machines sometimes up to 5 minutes for the ICU to load to browse the interfaces on the machine.
The amount of data transferred on startup will depend on certain things like the amount and types of interfaces you are loading. You can view the amount of data transferred in Network Manager Statistics in PI SMT. Are you using our Interface Status Utility by any chance? This also might slow ICU startup in some cases.
Just to add to David Rodriguez's response, PI ICU stores the interface's current batch file and health tag information in the Module Database (MDB) on the PI Data Archive that the interface sends data to. The MDB stores the information in a hierarchy like the one shown below:
If you need to know how many bytes are traveling across the wire when ICU loads interfaces, then you will have to use a tool like Wireshark. I am not going to lie to you; it is going to be difficult. This link might help: https://ask.wireshark.org/questions/9805/measure-the-total-transmitted-byte-in-a-time-interval.
Five minutes seems really excessive. Is it set to only check with one PI server or is it trying to scan all known PI servers and timing out? Are there any messages in the local PI message log on the interface computer when you start PI-ICU?
There is a setting in ICU that controls whether it loads interfaces from only the default PI Server, a list of PI Servers, or all known PI Servers. This KB article describes the process more as well as how to change the setting under the section: III. Customize your default viewing preferences.
I would say that its between 1:30 to 3:00 minutes based on my actual stopwatch tests I just performed. I did verify that we are only looking at a single PI server.
I have heard that the comparison for the MDB files can take some time, it seems though that the .batch files are very small in size locally (500 kb), I would think over a robust network this would be minimal time overall unless it is an application issue?
"PI ICU stores the interface's current batch file and health tag information in the Module Database (MDB) on the PI Data Archive that the interface sends data to."
Are there any messages in the local PI message log on the interface computer? You can use AboutPI-SDK / PI-SDK Utility to view those. You should only see two messages:
For my laptop connecting to my (slow) PI test server, it took 12 seconds for PI-ICU to completely load and another 7 seconds to select and load a specific PI interface instance. This is typical in my experience with clients' systems.
Looks like as follows (2 minutes)..also getting a strange error that pops up regarding impersonation which I found in an older KB article: KB00572 - PI SDK Buffering: Benefits, installation, configuration and other FAQs
01/04/2016 1:47:22:858 PM: Unable to Obtain the impersonation request token form the server. Continuing with buffer registration. This server version doesn't support impersonation requests. : 0x800404e1
01/04/2016 1:47:22:811 PM : Information, Successfully connected to server pi-server as xxx
01/04/2016 1:47:20:7201 PM : Information, Connection accepted:
Check your trusts and the PI server message log to see how you are authenticating.
Also, once PI-ICU finishes loading, select Tools -> Buffering and check the Global Buffering Status (if you have a newer version of pibufss). Then pull down View in the Buffering Manager and select Settings and check your authentication.
Chances are there is either no trust for your interface computer or some kind of mismatch between the PI server security settings (last item in PI-SMT) and how the interface computer is trying to authenticate.
It's possible that you might be running into this known issue: 94613 - ICU takes a minute to load on the ISU part
The reason is because ICU is searching for ISU instances on all nodes which have instances registered on this PI server. ICU has a status bar at the bottom. Do you see this message "Searching for ISU Instances for node:xxxxx"
I wanted to follow up on this thread, please let us which solution solved your issues by marking the correct answer.
If you found another solution it would be very interesting for future references!
Thank you .
Retrieving data ...