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.
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:
- Archiving of old data out of the station to some long term storage to minimize the size is a good idea.
- Using subscriptions to trend data in the third party system
- Use exports to get historical data that won’t be as susceptible to increased history read times.
