It may take a significant amount of time to get one instance back because getting history instances requires several network calls. GetInstances and related methods make a WCF call to the Notifications scheduler which then queries the history pi server. Therefore getting a single instance could take a similar amount of time to getting multiple instances.
In Notifications 2010 R2, we started caching history information to reduce the number of calls to the history pi server and improve the performance of history requests. This service is provided by the History Provider. However, the notifications must be running to be cached by the history provider. Having all your notifications disabled is causing you to query the pi server for history. Enabling the notifications should improve your performance for GetLastInstances because those instances will be loaded by the history provider.
There is one other gotcha for history provider. Requests for instances from it are all or nothing. If any part of your history query for GetInstances falls outside the cache period (default is last 7 days, but this can be configured) then whole time period is requested from the pi server.
Ok, thanks. Nice to know.
I'll be focusing on the notifications themselves again soon, so we'll just have to forget about the bad performance until then I guess.
I do, however, have a suspicion that the data collector function in my "ActiveX control" in ProcessBook is running several times when opening a display, so I'll get some logging in there and see.
I am using the ANNotificationList.GetInstances(AFTime startTime, AFTime endTime) to get all notification instances within an AF Database for a specific time frame.
I have noticed that when I call this function right after I restart the PI Notification Scheduler, it takes a considerable amount of time for this function to return.
It did not time out or throw any exception, it eventually returned the expected result.
I am wondering if this behaviour is related to the History Provider service you described above. Could you please give us some more detail about this service?
Where is this service running?
Where does it cache the notification history?
How does this service behave in a high availability environment (PI Collective, AF Collective and HA PI Notifications)?
2 of 2 people found this helpful
It may be related to the History Provider. History Provider is not a separate service but merely a process that the PI Notifications Scheduler service manages. It keeps an in memory cache of the Notification history for running notifications. Each notifications service instance is going to have a PINotificationsManager process, PINotificationsHistoryProvider, and 0 or more PIAnalyticsProcessor instances. When you make a GetInstances call, you connect to the primary manager who then requests the information from the history provider instance on the machine where the notification is running. The primary manager returns this information to you. The history provider acts as a cache. Based on the requested notifications and time interval, it checks if it has loaded those instances, if not it retrieves the instance information from the history PI server. So some slowness in response at startup could either mean that manager/history provider is blocked during the loading process or that the history PI server is slow to respond (not surprising given we are trying to request a lot of history at startup for a large system).
I would look at whether the Notifications service history performance counters are showing a lot of misses or hits. A lot of misses might indicate slow PI server response while low for both would indicate we are blocking your call before it even gets to history provider.