Optimizing a Datasource Connection

Overview

Seeq provides several parameters to optimize the connection to a datasource. This guide will go through these options.

Throttling Request Activity

Reducing the number and size of Seeq-initiated queries to a datasource may be useful if a datasource has performance issues. By default, Seeq will break up queries to the datasource into chunks of 1,000,000 samples, but sometimes that's still too large for a particular datasource. Furthermore, you may find that too many simultaneous requests results in out-of-memory errors for the datasource or the Seeq connector.

These behaviors are controlled per datasource connection using the following configuration properties.

These values can be set in the Datasources tab of the administration page. Expand the card of the datasource that you are interested in and click Configure.

Note reducing the max samples per request and the max concurrent requests will decrease pressure on the datasource; However, this can potentially result in slower overall performance for the end user in Seeq.

Prevent Requests into the Future

In some cases, datasource requests may be made that extend far into the future. This is because Seeq makes no assumptions about where data may exist in a datasource (to support use cases like forecast signals) and because some calculations require an expanded time range from their inputs to satisfy a given output time range (for instance, a moving average or smoothing operation).

This can lead to poor datasource performance if the datasource is not optimized for quickly responding when an empty region is queried. The Request Interval Clamp property can be set to truncate queries to stored signals or conditions, limiting the request interval relative to the Seeq server’s now. Set the property to a duration, such as 1 hour, and no request will be made to that signal or condition that extends more than 1 hour beyond the current time.

This property is typically applied using Connector Property Transforms. See Applying a Request Interval Clamp for an example.

Enabling Cache for Data that Changes

Connectors can return different values at a particular timestamp due to data changing in the historian. For example, the value of a particular signal at 1:00pm may be 100 watts at first, but as more data is added, the value is retroactively corrected to 110 watts. (OPC-HDA implementations have been reported to do this.) This behavior can cause problems in Seeq when the original value is cached, either in the signal itself if caching is enabled, or in calculations that reference the signal.

You can tune how much of a signal from the historian should be considered certain (and therefore cacheable). If you set the Uncertainty Override property for a signal to 1 hour, the last hour of the signal will be considered uncertain, and therefore not cached.

The same Uncertainty Override property is applicable to conditions. Setting it for a condition to 1 day, it will make the data uncertain starting 1 day before the current time.

Reducing Multiple Requests for the Same Data

There are situations where calculations and updates to the UI are taking too long due to uncertain data near-now being constantly requested by calculations and user behavior, such as a frequently auto-updating signal or conditions.

Multiple requests for the same data can decrease Seeq and the datasource performance. To prevent this issue, you can apply a debounce duration property to each affected signal or condition in the datasource. This property ensures that Seeq does not retrieve the same items from the datasource within the specified duration.

This property is typically applied using a Connector Property Transform.