Engine Performance and Tuning
Find the bottleneck before changing anything — source latency, database, model shape, and the concurrency settings.
"Infohub is slow" is almost always one of four things, and they need opposite responses. Identify which before changing any setting, because the wrong adjustment usually makes it worse.
Find the bottleneck first#
| Bottleneck | Signature |
|---|---|
| Source latency | Retrieval slow; the source system is slow when queried directly |
| Database | Everything slow; SQL Server busy; storage saturated |
| Model shape | Slow in proportion to the number of measures, especially minutely ones |
| Concurrency settings | Server and source both idle, yet work is not progressing |
The diagnostic that separates them: watch resource use during a pass. If the Infohub server, the SQL server, and the source are all idle while the engine works, the constraint is concurrency. If the source is busy, the source is the constraint. If SQL is busy, the database is.
Raising concurrency when the source is already saturated makes retrieval slower, not faster, and annoys whoever owns the source.
Source latency usually dominates#
For most deployments this is the answer.
Historian queries are the slowest thing Infohub does. If a historian takes four seconds to answer, no amount of CPU on the Infohub server helps — and four hundred measures × four seconds is over twenty-six minutes of pure waiting per pass.
What to do:
Time the source directly. Query it with its own client for the same window and see how long it takes. This tells you immediately whether the problem is Infohub's at all.
Retrieve raw and aggregate in Infohub. One query per tag, not one per tag per interval. Retrieving hourly, daily, and monthly versions of the same tag separately triples the query load — and invites the three to disagree. See Retrieved Measures.
Do not retrieve the same tag twice. If two metrics need one tag, one retrieved measure can feed both through the chain.
Tune concurrency to the source's tolerance. Raise MaxConcurrentConnections on the connection until the source becomes the constraint, then stop. Ask the source's owner what it will bear.
Move the connection closer. A connection hosted on a Platform inside the plant network avoids WAN latency on every query.
The database#
SQL Server does most of Infohub's real work.
Give it resources. Memory and fast storage matter more than CPU. Infohub's write pattern is many small inserts and updates across the calculation window, which spinning disks handle badly. See Hardware and Software Requirements.
Keep it close. The chatter between the engine and the database is frequent and latency-sensitive. An Infohub server in one region talking to a database in another will disappoint regardless of how large either is.
Maintain it. Index fragmentation and stale statistics degrade Infohub noticeably. See Database Maintenance.
Separate data and log volumes for anything beyond a small deployment.
Model shape#
Some models are intrinsically expensive, and the cost is set at design time rather than tunable afterwards.
Minutely measures are sixty times an hourly one. And everything above them inherits that volume. A few thousand minutely measures behaves like a much larger model. Use minutely only where the resolution is genuinely needed — peak demand, short-cycle equipment, process analysis — not as a default.
Long chains cost more than short ones. Each level is work. Building every interval to yearly for every tag creates a large model where most of it is never opened.
Rolling windows over fine intervals are expensive. A 30-day window on a minutely measure reads a great deal per evaluation. Prefer windows over the coarsest interval that answers the question.
Wide fan-out multiplies. One tag with eight aggregations plus three calculations is twelve measures. Multiply by every tag and the model size is a design decision, not an accident.
Only build the intervals someone uses. A quarterly measure nobody has ever opened still costs storage and calculation on every pass. Add intervals when they are requested. This is the cheapest performance improvement available in most models, and it is a modelling discipline rather than a setting.
Concurrency settings#
Two engine properties control parallelism:
| Property | Controls |
|---|---|
| MaxConcurrentMeasures | Measures processed in parallel |
| MaxConcurrentEvents | Events processed in parallel |
Raise them when the Infohub server, the database, and the sources are all under-used and work is still not progressing. Lower them when a source or the database is saturated.
There is no universally correct value — it depends on source tolerance, database capacity, and model shape. Change one setting, observe a few passes, then decide. Changing several at once means you learn nothing.
Poll controls how often the engine looks for work. A shorter poll makes values appear sooner and wakes the engine more often to find nothing. For hourly reporting, minutes is ample; seconds is waste.
Partition across engines#
Where one engine cannot keep up, split the model. An engine owns metrics, time schemes, and event schemes, so work divides by assignment.
Useful when:
- A slow source holds up everything else. Give it its own engine so the rest stays current.
- Heavy reporting competes with operational collection. Separate them.
- You want to use more than one machine. Engines on different Platforms run on different servers.
Do this in response to a diagnosed problem rather than pre-emptively. Several engines are more to operate, monitor, and reason about — and every metric, time scheme, and event scheme must be assigned to one, or it is silently never processed.
Backfills#
A backfill is the largest thing Infohub ever does, and it competes with current collection.
Bound it. Backfill a few weeks, confirm the values are right, then extend. Backfilling a year against a misconfigured measure produces a year of wrong values that then has to be rebuilt.
Do it off-peak. Overnight or at a weekend.
Expect knock-on effects. Every aggregation and calculation above the backfilled measure recalculates for that range, and every consumer resends those periods. A backfill against a metered downstream destination can be an expensive surprise for somebody else.
Warn people. Whoever watches the central instance in a multi-site deployment, and whoever owns any consumer destination.
The freeze point as a performance setting#
The freeze point is usually thought of as protection, and it is also a performance control: it stops the engine re-examining history on every pass.
An instance with no freeze point on a model with years of history is doing avoidable work continuously. Move the freeze point forward as periods are finalised.
Do not set it too close to the present, though — sources deliver late, and a freeze point of "yesterday" discards legitimate values. See Interval Types and Time Schemes.
Measuring rather than guessing#
Watch resource use during a pass on the Infohub server, the SQL server, and the source. Whichever is busy is the constraint.
Time the source independently. It separates Infohub's problem from the source's.
Track how long a pass takes over weeks. A gradual increase points at model growth or database maintenance; a step change points at something that changed on a date.
Track database size. Growth tells you about retention and interval choices.
Turn on Diagnostic temporarily for detailed engine logging when investigating, and turn it off afterwards — it produces a great deal of output.
What not to do#
Do not raise concurrency blindly. If the source is the constraint, this makes it worse.
Do not add minutely measures speculatively. They are the most expensive thing in a model.
Do not shorten the poll to make things faster. It does not; it adds load.
Do not skip database maintenance and then blame Infohub.
Do not change several settings at once. You will not know which helped.