Configuring Ignition Tag History for Faster Trend Queries

A three-day trend request across several tags drove processor utilization close to maximum, logged query times of one to four minutes, and returned no charted data. The installation used Ignition 8.1.52, SQL Server 2022, a scripted Time Series chart, and system.tag.queryTagHistory with calculated intervalSeconds, returnSize, and aggregationMode='MinMax'. Treat this as a query-scaling and display-design problem: measure each stage before changing aggregation or database settings.

Why do the usual fixes fail?

Increasing returnSize appears attractive because a zoomed trend needs more detail. On a wide time range, however, it increases the result set, aggregation work, data transfer, script processing, and chart rendering together. More returned points cannot make an already overloaded overview query faster.

Reducing intervalSeconds has the same failure mode. Smaller intervals create more time buckets over the selected range. Applying that interval to several pens multiplies the work by both bucket count and tag count.

MinMax preserves high and low excursions within each bucket, but it is not a license to request unlimited buckets. The historian and database must still find qualifying samples, group them, calculate extrema, and return the resulting rows.

Changing chart scripts before timing the history call also attacks the wrong stage. A scripted root.custom.pens object, generated series, and generated trends can add client-side work, but they do not explain a one-to-four-minute history query reported in the logs. Tuning does not fix wiring, and chart tuning does not fix an oversized historian request.

What causes the wide-range query to overload?

The request size grows along two axes: selected duration divided by the bucket interval, and the number of selected tags. A useful planning estimate is buckets per tag = selected duration / intervalSeconds. Estimated aggregate values then scale with the bucket count, tag count, and values emitted per bucket by the selected aggregation mode.

The signal chain matters. The historian reads stored samples, the query layer filters and aggregates them, the database executes the required operations, the Gateway receives and transforms the result, the script constructs chart data, and the Time Series chart renders it. A delay or excessive volume early in the chain propagates through every later stage.

How should the overview and zoom queries work?

Use separate resolution policies for overview and detail. The overview needs enough buckets to expose process shape and anomalies, not every stored sample. The zoomed request can use a smaller interval because the selected duration is shorter.

1. Read the selected start time, end time, and requested tags. Reject an inverted or empty range before calling the historian.
2. Build the tag list once from root.custom.pens. Remove duplicates and omit disabled or invisible pens unless the application explicitly needs them.
3. Choose a target chart-point budget based on what the display can use. Derive the interval from the selected duration rather than applying one fine interval to every range.
4. Calculate a preliminary interval as selected duration / target bucket count. Round it upward to a practical whole-second value so the request does not exceed the budget.
5. Call system.tag.queryTagHistory with the derived intervalSeconds and aggregationMode='MinMax'. Keep returnSize aligned with the same point-budget policy rather than independently increasing both controls.
6. When the operator zooms, issue a new query for the zoomed start and end times. Recalculate the interval for that shorter span instead of filtering a huge high-resolution overview result in the chart.
7. Do not launch a new history request for every transient zoom or date-control event. Trigger the query after the application has accepted a stable selection, and prevent an older slow request from replacing a newer result.

This creates progressive disclosure: coarse but anomaly-preserving data across the wide view, then finer buckets over the area selected for investigation.

How do you locate the expensive stage?

Look at the trend first, then measure the pipeline. Use the same three-day range from the reported case as a repeatable test, but begin with one tag. Record the history-call duration and returned row count before generating series or assigning data to the chart.

1. Run one tag with the overview interval and record query time.
2. Add tags one at a time. A roughly increasing duration identifies query volume as the main scaling factor; an abrupt change points to a particular tag or its stored history.
3. Keep the tag set fixed and compare a short range with the three-day range. This isolates time-bucket growth.
4. Time the script transformation separately from system.tag.queryTagHistory. Do the same for chart assignment and rendering.
5. Correlate Ignition log timestamps with SQL Server activity and host processor utilization. Identify whether the long interval occurs during database execution, Gateway processing, or chart work.

If the history call dominates, inspect the generated request dimensions and the database execution path. If transformation dominates, reduce repeated copying and rebuilding of datasets. If rendering dominates, lower the display-point budget even when the database can return more data.

How do you verify the revised query policy?

Verification must cover speed and anomaly retention. Test the same tag set and time span before and after the change, then compare query duration, processor utilization, returned rows, script-transform time, and chart-render time.

Confirm that MinMax still exposes narrow excursions in the overview. Zoom into several extrema and compare the detailed result with the overview envelope. The zoom request should produce finer temporal resolution without changing the selected process interval or silently dropping a pen.

Exercise repeated zoom-in, zoom-out, and date-range changes. The latest selection must win, the display must not flash stale results, and simultaneous requests must not accumulate. Also test no-data ranges, disabled pens, duplicate pen definitions, and a single-tag request.

Which pitfalls recur in historian trend designs?

Do not tie display width directly to raw historian resolution without a cap. Screen pixels limit useful visual detail, while the database cost continues to rise beyond that point. Do not use a single interval policy for both overview and forensic views.

Avoid querying tags that the chart will not render. Validate the final list after all scripted pen rules run. Keep query execution separate from series construction so logs and timings identify the responsible stage.

Do not treat 8.1.52 or SQL Server 2022 as the cause solely because those versions appear in the installation. First reproduce the scaling relationship with controlled tag counts, ranges, and intervals. A version or database defect requires a repeatable case that remains slow after the request size is bounded.

FAQ