Ignition Perspective session capacity is a property of the complete data path, not a fixed session-count limit. A browser requests pages from the front-end gateway; the gateway evaluates bindings and scripts, subscribes to tags, processes updates, renders session state, and sends changes back to the client. Follow that path while adding representative sessions. A lightly loaded deployment reached 165 sessions with room remaining, while a heavier deployment reportedly reached its practical limit near 50.
What workload does each Perspective session create?
Start at the client. Each open session adds browser-to-gateway traffic, gateway-managed session state, page instances, bindings, subscriptions, scripts, and outbound updates. The cost depends on which pages users open and how often their underlying values change.
| Path stage | Load source | Commissioning observation |
|---|---|---|
| Browser | Open pages, component count, client rendering, and received updates | Check browser responsiveness and confirm the intended page is open. |
| Network path | Concurrent connections and update traffic | Check latency, retransmissions, disconnects, and reconnects along the actual client path. |
| Front-end gateway | Session state, bindings, scripts, tag subscriptions, and update processing | Check resource utilization and Perspective diagnostics while session count rises. |
| Tag and data sources | PLC tags, calculated tags, queries, and other requested data | Check subscription counts, request rates, query duration, and source response time. |
A simple display designed for viewing from 5–10 meters can still serve many users efficiently when it presents a limited data set with simple graphics. Visual size is not the deciding factor. The number of changing values and the work triggered by each change matter more.
Check: open the representative production page, trace its values back through the gateway to their sources, and account for every recurring request or update before increasing the test population.
Which page should define the load test?
Use the busiest realistic page, not a blank landing page. A session count measured with an idle or lightweight view does not predict capacity when users navigate to a page containing thousands of points, frequent updates, multiple repeaters, or per-element scripting.
| Observed workload | Reported session result | Engineering interpretation |
|---|---|---|
| Thousands of data points updating every second, a couple dozen flex repeaters, and scripting on every element | Practical maximum around 50 sessions | Per-session page work dominated capacity. |
| About 100 values, with most work performed by tags | 160 sessions at about 20% usage | Lower page intensity left substantial gateway headroom. |
| Simple, cartoon-like operational display with limited data quantity | 125 sessions without appreciable gateway strain; later 165 sessions with room remaining | Simple presentation can support a higher session count, subject to the rest of the gateway workload. |
| Large ad hoc trend subscription | Only 3–5 sessions were slow | A small number of sessions can overload the data path when each one requests excessive data. |
Build a session mix that matches operations: the expected share of users on the busiest page, normal navigation, normal idle time, and any displays that remain open continuously. If dock-door displays normally show the same performance-to-plan page, reproduce that concentration instead of distributing synthetic users across easier pages.
Check: compare the test page’s component, subscription, repeater, script, and update profile with the production page. Continue only when the profiles match closely enough to exercise the same bottleneck.
How should tag subscriptions be controlled?
Layer one first: verify that the physical and network path is stable before tuning application behavior. Then inspect the request fan-out behind each page. One slow system served only 3–5 sessions because users had dragged PLC tags into trends. Removing approximately 50,000 trended tags improved the situation. The limiting factor was requested data volume, not the displayed session number.
| Symptom | Likely path location | Diagnostic | Corrective action |
|---|---|---|---|
| Low session count but poor response | Tag subscription or history path | Inspect active trend pens, tag subscriptions, and query activity. | Remove unused pens and prevent unrestricted bulk tag selection. |
| Load rises sharply on one page | Page bindings and scripts | Compare utilization before and after opening that page. | Reduce unnecessary bindings, repeated components, and event-driven work. |
| Values arrive late while the gateway appears stable | Network or upstream data source | Check link errors, latency, source response, and update age. | Repair the failing hop before changing the Perspective project. |
| Many sessions run with modest utilization | No immediate bottleneck | Observe utilization and response through a sustained test. | Increase load in controlled steps until the acceptance threshold or resource limit is reached. |
Trend configuration deserves separate scrutiny because a single user can subscribe to a very large tag population. Place practical limits on selectable pens, default time ranges, and automatic subscriptions. Move repeated calculations into shared tag logic where that reduces duplicated session work, but verify that doing so does not merely relocate the bottleneck to the tag subsystem.
Check: record the active subscription and query load with the busiest page open, remove unintended requests, and confirm that gateway response improves without changing the session count.
What gateway baseline must be recorded?
Measure the front-end gateway before adding test clients. Record processor utilization, memory behavior, active session count, tag activity, script execution, query activity, and network throughput using the gateway’s available diagnostic views. Capture both an idle period and a normal production period so background work is visible.
The reported 165-session installation did not include its server specification in the text record. A request for that specification was made, but no processor, memory, storage, operating-system, or virtualization details were recorded. The session result therefore cannot be transferred to another gateway by count alone.
| Setting or condition | Value to record | Why it matters |
|---|---|---|
| Gateway host | Actual processor, allocated memory, storage, and virtualization limits | Defines the resources available to all sessions and background services. |
| Client address path | Client segment, routing hops, and gateway endpoint used in production | Separates gateway saturation from path-specific network faults. |
| Listener and intermediary ports | Configured gateway listener and any proxy or firewall mappings | Confirms that every test session follows the production connection path. |
| Update timing | Actual tag, query, and page update rates read from the project configuration | Determines how often each session generates work. |
| Background services | Tasks sharing the gateway during the test | Prevents an unrealistically quiet test from overstating capacity. |
Check: save a timestamped baseline with the production network path and background workload active. Do not use a session count from another host as the baseline.
How should concurrent sessions be added?
Increase sessions in measured stages while keeping the page mix and user behavior constant. The test must run long enough to expose accumulating memory, queued work, reconnect activity, and periodic background tasks. Do not treat a momentary successful page open as a capacity result.
- Open the representative page on one session and verify every displayed value, binding, trend, repeater, and script-driven action.
- Record gateway and network measurements at the established baseline.
- Add a controlled group of concurrent sessions through the same address, port path, and intermediaries used by production clients.
- Wait for the session population and update traffic to stabilize, then repeat the same user actions and record response.
- Increase the population again only if page response, data freshness, gateway resources, and connection stability remain inside the project’s acceptance limits.
- Stop when an acceptance limit is crossed, identify the first saturated path stage, correct it, and rerun the same stage.
Quality-assurance testing described for this product exercises 100 concurrent sessions and treats failure below 100 as a regression; it does not define 100 as a universal maximum or guaranteed production capacity. Support experience cited 140–150 sessions, while installation observations ranged from about 50 on a heavy page to 165 on a lighter application.
Check: at each stage, confirm that all sessions remain connected and that the same scripted action produces the same result and response profile as the single-session test.
Where does the request path stop when performance degrades?
Follow the packet. If the browser is slow but the gateway processes updates normally, inspect client rendering and the network path. If gateway utilization or queued work rises when a particular page opens, inspect that page’s subscriptions, repeaters, bindings, and scripts. If values are already stale when they reach the gateway, inspect the upstream tag or data source.
| Observation during staged load | Decision | Next measurement |
|---|---|---|
| Only clients on one network segment degrade | Treat the path as the primary suspect. | Compare latency, loss, and connection behavior with a healthy segment. |
| All clients degrade when the same page opens | Treat page workload as the primary suspect. | Measure the change in subscriptions, scripts, queries, and gateway resources. |
| Data becomes stale before gateway resources rise | Treat the upstream source as the primary suspect. | Measure source response and tag update age. |
| Memory or processor demand grows with every session | Determine which per-session function scales with the count. | Compare one-session and multi-session page diagnostics. |
| A few trend users cause a disproportionate slowdown | Treat bulk trend subscriptions as the primary suspect. | Count active pens and remove unused tag requests. |
Change one workload dimension at a time. Reducing update rates, removing subscriptions, simplifying repeaters, and disabling scripts simultaneously may improve performance, but it hides the actual constraint and makes the result difficult to reproduce.
Check: make one corrective change, repeat the failing load stage, and verify that the measured bottleneck moves or disappears while other conditions remain constant.
How is production capacity accepted?
Define capacity as the highest tested concurrent population that meets the project’s response, freshness, connection, and resource criteria under the heaviest credible page mix. Include operating margin for background work and workload growth. A gateway showing no appreciable strain at 125 sessions may be tested higher, but 165 successful sessions on one installation does not establish a product-wide ceiling.
Run the acceptance population through the complete production path: client device, physical network, routed or proxied hops, front-end gateway, tag providers, databases, and controllers. Exercise page opening, navigation, value updates, trends, scripts, and reconnect behavior. Compare the results with the saved baseline and with measurements from every staged increase.
- Start the representative session population through the production endpoint.
- Open the busiest expected page mix and perform the normal user actions.
- Confirm that displayed values remain current and that scripts and navigation complete within the site’s defined limits.
- Confirm that sessions remain stable and that no network, gateway, tag, or query queue continues to grow.
- Repeat the test while normal background services are active.
- Record the accepted session count, page mix, update behavior, gateway specification, and measured headroom as one capacity result.
Check: repeat the busiest user action simultaneously across the accepted session population and verify correct data, stable connections, bounded resource use, and no accumulating work at any hop.
FAQ
What happens if Ignition Perspective exceeds 100 concurrent sessions?
Nothing changes solely because the count passes 100. Testing cited 100 concurrent sessions as a regression threshold, while field observations reached 140–150 and one installation reached 165; page workload and gateway headroom decide the result.
What happens if only a few Perspective sessions are slow?
Inspect the data requested by each session before blaming the count. One 3–5-session system improved after approximately 50,000 unnecessary trended tags were removed.
What happens if a heavy Perspective page limits capacity?
Measure its changing points, repeaters, bindings, scripts, trends, and queries, then remove one unnecessary workload source at a time. Repeat the failed concurrency stage and verify current data, stable connections, bounded gateway resources, and no growing queue across the end-to-end path.