romanettandClaude Opus 5.5
484596c2a8
# Description Low-risk speedups in the server event delivery path. With many event monitored items on one notifier (750 on the Server object in the `events` harness scenario), a single `MonitoredNode2` consumer thread delivers every event to every item and is 100 % busy, which caps the server at ~770 events/s. This PR makes the per-item work cheaper. There are no public API or wire changes. Each commit stands alone: 1. **Server: dequeue events in O(1).** `EventMonitoredItemQueue.Dequeue` used `List.RemoveAt(0)`, which shifted every queued event. It now advances a head index, compacts the list once the dequeued slots are half of it, and clears it when it runs empty. Discard oldest/newest, the `SetQueueSize` truncation and the newest-1000 duplicate range are unchanged. The mirroring redundancy queue snapshots only the queued range. 2. **Server: reuse the event filter context of a monitored item.** `QueueEvent` created a `FilterContext` per event and item. The item now keeps it until the session replaces its `PreferredLocales`. `GetEventFields` writes into a `Variant[]` instead of a `List` that was then copied, and translates with the context's locales instead of looking up the session per LocalizedText field. 3. **Server: check event duplicates against an index of the newest entries.** `IsEventContainedInQueue` loaded the handle of up to 1000 queued entries per item and event. A reference-keyed count of the event instances in the newest 1000 entries, kept current by `Enqueue`/`Dequeue`/`SetQueueSize`, makes it one lookup. The checked range is the same, and wrapped filtered-retain handles count as their instance. If a derived queue changes `m_events` directly, the index is rebuilt. 4. **Core: evaluate an empty content filter without an evaluator.** `ContentFilter.Evaluate` created a `FilterEvaluator` and, through the telemetry context, a new logger for every evaluation, also for the empty where clause of most event filters (~16 % of the scenario's allocated bytes). An empty filter now passes directly, and the evaluator creates its logger only to log a failure. 5. **Core: give the fields of an initialized event a source timestamp.** `BaseEventState.Initialize` created its field variables without a timestamp, so `BaseVariableState.ReadValueAttribute` called `DateTimeUtc.Now` on every read of every field for every monitored item. The fields now carry the event time (`ReceiveTime` its own value). The read path is unchanged, so no `ReadChildAttribute`/`ReadValueAttribute` override is bypassed. ## Measurements `perf/ServerLoadHarness run --scenario events --sessions 50 --subs 15 --pub 100 --security encrypt --event-rate 0 --duration 15 --warmup 8`, with `DOTNET_gcServer=1`, `SERVER_DOTNET_gcServer=1` and `SERVER_DOTNET_TC_QuickJitForLoops=0`, `SERVER_DOTNET_TC_OnStackReplacement=0`. Each build is stacked on the previous one; values are the mean of 2 alternating rounds. Runs where processes outside the harness used more than 1.5 cores were repeated. | build | generated events/s | event→notify p50 | KB / generated event | ms CPU / generated event | |---|---|---|---|---| | master | 768 | 69.8 ms | 567 | 2.97 | | + O(1) dequeue | 791 | 68.4 ms | 566 | 2.78 | | + filter context reuse | 818 | 68.8 ms | 354 | 2.75 | | + duplicate index | 854 | 63.7 ms | 356 | 2.96 | | + empty where clause | 891 | 63.7 ms | 273 | 2.77 | | + event field timestamps | **1001** | **61.3 ms** | **272** | **2.66** | - **`--event-rate 500` (below capacity):** 3.34 → 3.03 ms CPU and 590 → 294 KB per generated event. Latency is unchanged (bound by the publishing interval). - **Default JIT, 40 s warm-up:** 804 → 1063 events/s, 568 → 268 KB, 2.69 → 2.37 ms. - **CPU traces:** the consumer thread's `ReadValueAttribute` self share drops from 24 % to 6 % of the samples and `QueueEvent` self from 14 % to 5 %. The thread is still the bottleneck, now in the generic read chain (`GetAttributeValue` → `ReadChildAttribute` → `FindChild`). The next step would be to evaluate each event once per distinct filter rather than per item, which is out of scope here. ## Notes for reviewers - `EventMonitoredItemQueue.m_events` keeps its protected `List<EventFieldList>` type, but dequeued slots now stay null at the front until compaction. The queued events are the last `ItemsInQueue` entries. Nothing in the repository reads the field outside the class except the mirroring queue, which uses the new internal `CopyQueuedEvents()`. - Event field variables created by `Initialize` now report the event time as `SourceTimestamp` instead of the time of the read. ## Related Issues - No issue. Found by the server load investigation of publish-, write- and event-heavy load. ## Checklist - [ ] I have signed the [CLA](https://opcfoundation.org/license/cla/ContributorLicenseAgreementv1.0.pdf) and read the [CONTRIBUTING](https://github.com/OPCFoundation/UA-.NETStandard/blob/master/CONTRIBUTING.md) doc. - [x] I have added tests that prove my fix is effective or that my feature works and increased code coverage. - [x] I have added all necessary documentation. - [x] I have verified that my changes do not introduce (new) build or analyzer warnings. - [ ] I ran **all** tests locally using the **UA.slnx** solution against at least .net **framework** and .net **10**, and all passed. (net10.0 only: Opc.Ua.Server.Tests 8990 passed, Opc.Ua.Core.Tests 6449 passed, Opc.Ua.Redundancy.Server.Tests 922 passed. In the explicit Sessions `ServerEventSubscribeLoadTest`, opc.tcp passes; https and opc.https fail with HTTP 503, the same as on master.) - [ ] I fixed **all** failing and flaky tests in the CI pipelines and **all** CodeQL warnings. - [ ] I have addressed **all** PR feedback received. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
OPC UA .NET Standard Stack
🆕 This is version 2.0 of the OPC UA .NET Standard Stack (current
master).Looking for the supported 1.x release? It lives on the
master378branch (last release:1.5.378). All new feature work happens here onmaster;master378continues to receive security and critical-bug fixes for the 1.x line.
The official OPC Foundation reference implementation of OPC UA for .NET — a certified, cross-platform stack with client, server, PubSub, GDS, complex types, and source-generated tooling. Used in production across industrial control, manufacturing, energy, and IoT systems.
📦 What it is
- A full-stack OPC UA implementation — Core / Client / Server / PubSub / GDS / LDS / Complex Types / Device Integration / Positioning libraries built on .NET, with UA-TCP and HTTPS transports.
- Cross-platform — runs on .NET 10, .NET 9, .NET 8 (LTS), .NET Framework 4.8; ships Native-AOT-friendly assemblies.
- Certified for compliance — the reference server has been certified through an OPC Foundation Certification Test Lab and is continuously verified against the latest Compliance Test Tool (CTT).
- Companion-spec coverage — Part 9 (Alarms & Conditions), Part 10 (Programs), Part 11 (Historical Access), Part 13 (Aggregates), Part 16 (State Machines), Part 17 (Alias Names), Part 18 (Role Management), Part 20 (File Transfer), Part 100 (Device Integration), Part 110 (Asset Management Basics), Parts 210/211 (Relative Spatial Location and Global Positioning), OPC-10030 (ISA-95 Common Model) with OPC-10031-4 Job Control V1/V2, OPC 30270 / OPC UA for Asset Administration Shell V2 and V3, OPC 10100-1 (WoT Connectivity), Part 200 (Industrial Automation), OPC 40001-1/-2/-3/-4/-101 (Machinery with Process Values, Job Management, Energy and Result Transfer), OPC 34100 (Energy Consumption Management), OPC 30081 (PA-DIM), OPC 40010-1 (Robotics), OPC 40100-1/-2 (Machine Vision control and asset management), OPC 40501-1 and OPC 40505 (Machine Tools and independent wireless peripherals), OPC 40210 (Geometric Measurement Systems, with its documented upstream Production-facet exception), OPC 40020-1 (Cranes and Hoists), OPC 40223 (Pumps and Vacuum Pumps), OPC 40200 (Weighing Technology) with OPC 30050 (PackML).
- Hosting and code generation —
Microsoft.Extensions.DependencyInjectionhosting (services.AddOpcUa()), fluent server + client builders, source-generated NodeManagers and DataTypes, and an MCP server so LLMs / Copilot can drive an OPC UA client.
For the full feature breakdown see OPC UA Profiles and Facets and the What's New in 2.0 tour.
🚀 Getting started
To run a first OPC UA client and server, from NuGet packages or from the samples in this repository, follow Getting started. The documentation index then leads from the core concepts to advanced and experimental features.
The recycling operator console demonstrates live browser monitoring, native companion-specification inspection, material genealogy, and authorized controls over the synthetic recycling line.
You need the .NET 10 SDK to build the repo. From the repository root:
dotnet restore UA.slnx
dotnet build UA.slnx
For the supported target frameworks and platform notes see
the Developer Guide. The official NuGet packages
are published to nuget.org under the OPCFoundation.NetStandard
prefix — the meta package
OPCFoundation.NetStandard.Opc.Ua
pulls in everything, or reference individual packages directly, e.g.
OPCFoundation.NetStandard.Opc.Ua.Client for clients or
OPCFoundation.NetStandard.Opc.Ua.Server for servers. Preview builds from
every successful master build are available from the
GitHub Packages NuGet feed,
which is the only feed they are published to. nuget.org receives a version
only through a manually approved promotion from a release/<major>.<minor>
branch — that is where the 2.0.0-preview.N packages already on nuget.org
came from, via the earlier release/2.0.0 line. To use those, enable
prerelease packages and float with 2.0.0-preview.* until 2.0.0 is
released. The XRegistry, WoT Connectivity, Robotics, CranesHoists,
Redundancy, Positioning, OpenUSD, and AI package families, the Vision.OpenUsd
renderer, and the Robotics MCP extension remain
preview packages when the root version is promoted to a stable version, and
keep their own -preview.N versions on nuget.org. This includes all CranesHoists
model/server/client/MCP packages and their Debug variants.
The Vision, MachineVision, MachineTool (including WMTP), and GMS
model/client/server packages and their MCP packages follow the root version
without a preview-only override;
development builds still inherit the root prerelease version. See
docs/ReleaseProcess.md for how and when stable
versions are released.
Samples
The platform-independent sample applications show how to use the stack's core services and companion models in client/server workflows. More applications, including platform-specific examples, are available in the companion OPC UA .NET Samples repository.
Developer tools
- OPC UA MCP Server — installable .NET tool and container exposing OPC UA client operations to LLMs and Copilot. Embeddable libraries provide Part 4 services, PubSub, diagnostics, Robotics and Vision, plus industrial companion profiles for AMB, Machinery, Scales, Pumps, Device Integration, ISA-95 and Positioning. The WoT and xRegistry profiles add asset/registry management and bounded document validation, planning and NodeSet conversion. Stack workflow profiles provide GDS/credential issuance, roles/users, files, alarms, history, schemas, and host-authorized PubSub and live WoT execution.
🔧 Migrating from 1.5.378 to 2.0
The 2.0 release introduces breaking API changes, and comes with a full prescriptive migration guide that links to per-area documentation for the migration sub-topics.
Most of the mechanical migration work is automated:
OPCFoundation.NetStandard.Opc.Ua.MigrationAnalyzerNuGet — install it in your project to get 26 analyzer rules throughUA0030(excludingUA0013,UA0016,UA0017, and the shim-onlyUA0029) plus one-click code fixes for the patterns in the guide. Setup steps are in the package's NugetREADME.md.- Migration agent skill — the
opcua-v20-migrationskill walks Copilot / Claude / any coding agent through installing the NuGet, runningdotnet format analyzersto apply auto-fixes, and handling the remaining manual changes. It selects the migration sub-document for each symptom.
Copilot CLI discovers the skill automatically inside a clone. To install it for use in any repository:
copilot plugin marketplace add OPCFoundation/UA-.NETStandard
copilot plugin install opcua-v20-migration@opcua-dotnet
If you are still on 1.x and not ready to upgrade, stay on the
master378
branch — it continues to receive security and critical-bug fixes.
🤝 Contributing and license
Community contributions are welcome. Fork the repository, make your changes on a branch, and open a pull request; see CONTRIBUTING.md for the contribution workflow.
Contributors must sign the OPC Foundation Contributor License Agreement (CLA). The CLA "I AGREE" gate is presented automatically on your first PR.
The project is licensed under the OPC Foundation MIT License. Report security vulnerabilities via the process documented in SECURITY.md.
📚 Further reading
- Documentation index — every per-feature doc with a one-line description.
- What's New in 2.0 — narrative tour of the 1.5.378 → 2.0 changes grouped by theme and layer.
- OPC UA Profiles and Facets — facets / transports / security policies the stack implements.
- Migration Guide — prescriptive
per-version migration reference (links to
docs/migrate/2.0.x/). - OPC UA Online Reference — the official OPC 10000 series specification index.
- Preview Nuget package feed —
prerelease builds from every successful
masterbuild.