PI Vision performance: practical troubleshooting and tuning workflow
PI Vision “slowness” usually has multiple causes: browser rendering, authentication, AF queries, Data Archive load, network conditions, or concurrency when many users open the same heavy display. The goal is a repeata...
PI Vision performance: practical troubleshooting and tuning workflow
Meta description: A practical workflow to diagnose and improve PI Vision performance, from client rendering to AF queries, concurrency, caching and back-end bottlenecks.
PI Vision “slowness” usually has multiple causes: browser rendering, authentication, AF queries, Data Archive load, network conditions, or concurrency when many users open the same heavy display. The goal is a repeatable workflow that narrows the problem to one layer at a time and produces actionable evidence.
This guide is for PI Administrators and OT/IT architects working in live environments: how to reproduce the problem, what to measure, and which tuning changes are worth trying (and which merely move the bottleneck).
Refer to the wider PI performance context and objectives here: PI performance and scaling fundamentals.
Define “slow” precisely
Before changing config, make “slow” measurable. Typical user complaints fit three categories:
- Time-to-first-paint: the display frame appears slowly.
- Time-to-interactive: the frame appears but interactions (pan/zoom, navigation, symbol changes) lag.
- Time-to-fresh-data: the frame is visible but trends and values are slow to populate or refresh.
Record which symptom(s) occur, and whether it affects a single user, one display, a location, or everyone. “One display is slow” usually has a different cause than “PI Vision is slow for everyone”.
Quick triage: symptom → likely layer and causes
Use this as a first-pass checklist to direct measurement.
- Display loads but symbols stay “loading” → Back-end data retrieval (slow AF queries, heavy tag searches, Data Archive load).
- Navigation and time-range changes lag despite visible data → Server-side processing or browser rendering (concurrency spikes, large display definition, browser CPU).
- Only certain displays are slow → Display design/AF (many symbols, unique queries, inefficient templates).
- Everyone slow at the same time → Concurrency + shared services (shift change, batch jobs).
- Remote sites only → Network (latency, bandwidth, proxies/TLS inspection).
- One user slow → Client/device (extensions, endpoint security, old hardware).
- Trends slow or stutter when zooming → Rendering (too many traces/points, large ranges).
- Login or first request after idle is slow → Auth/session setup (IdP latency, Kerberos/NTLM, cold caches).
- Slowness during AF rebuilds/migrations → AF Server maintenance (indexing, cache warm-up).
Keep this list handy, then collect measurements to confirm.
Practical workflow: isolate the layer, then tune
-
Reproduce with a known display and a stopwatch
- Choose a single representative problematic display (or create a simple baseline). Use a consistent time range. Capture three metrics: time to frame shown; time to all symbols populated; time to update after a time-range change.
-
Rule out client and network issues early
- Measure latency and packet loss between client and PI Vision. Check DNS, proxies and TLS inspection. Test in a clean browser profile and monitor client CPU during interaction. This determines whether to focus on server logs or network/WAN conversations.
-
Decide whether the bottleneck is retrieval or rendering
- If symbols remain “loading”, suspect AF queries, Data Archive calls or server contention.
- If data appears quickly but interaction is sluggish, suspect browser rendering or display complexity.
- Quick test: duplicate the display and remove half the symbols. If performance improves roughly proportionally, it’s a rendering/display-complexity problem; if not, focus on expensive queries or server-side contention.
-
Examine concurrency, not averages
- Peaks (shift handovers, meetings) often reveal problems. Ask how many users were online and whether they viewed the same displays. Concurrency multiplies per-user cost; tune to reduce marginal work per user.
-
Analyse AF query behaviour
- Expensive patterns: many symbols each resolving different elements/attributes, dynamic searches instead of bindings, broad template/category searches, and large AF hierarchy scans.
- Mitigation: make asset selection explicit, scoped and reusable to reduce discovery work.
-
Consider Data Archive load and point density
- Distinguish “too much data requested” (long ranges, high-resolution tags, many traces) from “server too slow” (CPU, disk I/O, queueing). Even visually downsampled trends require server-side work. Monitor for cache misses and random I/O.
-
Don’t ignore rendering on the client
- Many symbols, tables or high-cardinality trends can overwhelm the browser’s layout/paint pipeline, especially on thin clients. Splitting “wallboard” displays into smaller, navigable views improves responsiveness.
-
Reduce work before adding resources
- Prefer changes that lower per-user work (fewer queries, scoped AF searches, reduced symbol count) before scaling hardware. If you must scale, do so after confirming the bottleneck to avoid masking design issues.
Tuning moves that usually pay off (with trade-offs)
- Reduce display complexity: split “kitchen sink” dashboards into a lightweight overview plus detail views. Trade-off: extra navigation.
- Scope AF selection: bind to known elements/attributes or tighten searches (template/category/context). Trade-off: requires governance and disciplined display authorship.
- Optimise default time ranges: avoid unnecessarily large defaults. Trade-off: investigators may change ranges more often—provide separate investigation displays.
- Design for concurrency peaks: optimise the most-viewed displays for peak load rather than average load.
Example: the morning meeting slowdown
Pattern: PI Vision is fine most of the day but slows at 08:55. Cause: many users open the same heavy displays simultaneously—broad AF queries and long-range, high-frequency data pulls. Fix: make meeting displays lighter (fewer symbols, tighter AF binding, sensible ranges) and ensure back end is sized for the peak. After tuning, required back-end capacity often drops significantly.
What not to do
- Don’t make multiple changes at once—measure before and after each change.
- Don’t assume every complaint is a server issue; network and client rendering are common causes.
- Avoid “add more hardware” as the first move; it often masks a design problem.
When to bring in specialist help
If you’ve isolated the bottleneck but need validation of a scaling design or controlled performance testing, consider a short engagement with an independent PI practitioner. Provide a reproducible slow display, peak concurrency numbers and AF query patterns.