Niagara Haystack+ hisRead speeds


#1

Hi there,

Currently we are experienceing perfromance issues with the hisread function using the API servelet (not the export method). approximatle 6 seconds per point when calling yesterday’s history

I can see that the thread count can be increased for the wathces with the hidden property however does this apply to the hisRead also?

Can you also confirm if the threadcount in the Jetty webserver affects the Haystack+ servlet in any way.

The station and server are abondent with resourcess and the physical network and internet speed is more than capable.

This is currently running on niagara version 4.6 and haystack+ driver version 1.0.20


#2

If you navigate to the Ops component on the Haystack Local Device under the Haystack Network, you will see an option called Web Threads. The default is 4 so you can increase that to something higher if you have a higher load of web calls coming in. With all thread tuning, you will need find a balance since too high a number will cause high memory usage and possible timeouts if too many threads are fighting for the same resources simultaneously.

image

The Jetty webserver is the original receiver of all web requests so everything that makes it to the haystack driver comes through it first so you will have to make sure it also has enough threads allowed. The web threads configured for the driver are just the number of web requests it receives that it can handle at the same time but those requests are passed to it via the jetty webserver.

As to the speed of the histories, how big of a history database would you estimate the Niagara station? The read speed of that database is directly affected by its speed. For example, if a new station had 5 days of histories and you read yesterday, it might take 0.5 seconds. If the station ran for a year and now had histories for that entire time and you read yesterday it might take 3 seconds. Even though you are not reading a larger time frame, the database gets slower in its access because of its size.

Some possible solutions to this issue:

  1. Archiving of old data out of the station to some long term storage to minimize the size is a good idea.
  2. Using subscriptions to trend data in the third party system
  3. Use exports to get historical data that won’t be as susceptible to increased history read times.