mirror of
https://github.com/OPCFoundation/UA-.NETStandard.git
synced 2026-10-17 05:11:13 +08:00
romanett
68f062eecc
## Description
Six small changes to the per-request path from the o6 benchmark gap
report (S1–S6), chosen from the allocation profile of the o6 read
benchmark (`AsyncCustomNodeManager`, Server GC, 10 clients × 100
single-value Reads in flight). Each change is its own commit. The
receive loop, its threading and its dispatch are not touched; there are
no wire, public API or generator changes.
### Results
Paired A/B runs, builds alternated per round, 5 rounds unless noted,
medians (min..max). Baseline: master d40843c23 with #4787, #4788 and
#4805 (all three merged since; this branch is rebased on master). Each
item was measured on its own on the baseline, and all six together. The
machine is shared with other sessions: a run during which another test
host or load harness ran was discarded and repeated. Allocated bytes per
request are deterministic; CPU per request is best read from the runs
pinned to 4 logical processors (`--server-affinity 0xF`, the 4 Zen 5
cores).
**Allocated bytes per request** (o6read 10 × 100, pinned):
| Node manager, security | baseline | S1 | S2 | S3 | S4 | S5 | S6 | all
|
|---|---|---|---|---|---|---|---|---|
| async, plain | 4,219 B | 4,114 (−2.5 %) | 3,631 (−13.9 %) | 4,057
(−3.8 %) | 4,123 (−2.3 %) | 4,099 (−2.8 %) | 3,511 (−16.8 %) | **2,411
(−42.9 %)** |
| async, encrypted | 4,267 B | −2.6 % | −13.8 % | −3.7 % | −2.4 % | −3.1
% | −16.5 % | **2,465 (−42.2 %)** |
| `CustomNodeManager2`, plain | 5,407 B | −2.1 % | −5.1 % | −3.0 % |
−1.8 % | −2.5 % | −12.9 % | **3,910 (−27.6 %)** |
| `CustomNodeManager2`, encrypted | 5,457 B | −2.0 % | −5.1 % | −2.9 % |
−1.9 % | −2.4 % | −12.9 % | **3,963 (−27.4 %)** |
**CPU per request, pinned to 4 logical processors:**
| Node manager, security | baseline | all six | each item alone |
|---|---|---|---|
| async, plain | 28.3 µs (27.8..29.8) | **27.1 µs (25.6..27.7), −4.2 %**
| −2.7 .. +1.9 % |
| async, encrypted | 31.5 µs (30.8..32.9) | 30.6 µs (30.1..40.1), −2.8 %
| −2.8 .. +0.8 % |
| `CustomNodeManager2`, plain | 34.0 µs (33.1..36.6) | **31.2 µs
(30.5..34.1), −8.1 %** | −5.0 .. +2.5 % |
| `CustomNodeManager2`, encrypted | 35.8 µs (35.0..38.9) | **34.3 µs
(33.5..35.2), −4.1 %** | −1.0 .. +3.8 % |
Garbage collections in the pinned plain run (300,000 requests): gen0 19
→ 12, pause 85 → 50 ms.
**After review (S6 with immutable codecs):** the tables above were
measured with a decoder and an encoder reset per message. Keeping
`BinaryDecoder` and `BinaryEncoder` immutable, so every message gets new
ones, costs about 214 bytes per Read: all six together allocate 2,625 B
per Read instead of 2,411 B in the pinned plain run (2 runs), −37.8 %
against the baseline.
**24 cores and the managed client** (all six against the baseline; the
managed scenarios 3 rounds):
| Scenario | baseline | all six |
|---|---|---|
| o6read 10 × 100, 24 cores: req/s | 296.3k (283.4..305.4k) | 302.2k
(245.0..323.0k) |
| same: allocated / request | 4,169 B | 2,349 B (−43.7 %) |
| o6read 10 × 1000, 24 cores: req/s | 297.4k (284.2..309.8k) | 295.6k
(269.6..311.5k) |
| same: allocated / request | 4,196 B | 2,373 B (−43.4 %) |
| `read --nodes 1`, 20 sessions: req/s, CPU / request | 259.3k, 40.2 µs
| 271.4k, 38.9 µs (−3.2 %) |
| same: allocated / request | 4,172 B | 2,444 B (−41.4 %) |
| `read --nodes 1`, 200 sessions: req/s, CPU / request | 257.1k, 36.7 µs
| 283.6k, **33.1 µs (−9.8 %)** |
| same: allocated / request | 4,041 B | 2,354 B (−41.7 %) |
| `read --nodes 100`: CPU / request | 226.1 µs | 214.9 µs (−5.0 %) |
| same: allocated / request | 72,379 B | 52,046 B (−28.1 %; S2 alone
−26.3 %) |
| `browse`: CPU / request (6 rounds) | 147.9 µs | 148.8 µs (+0.6 %) |
| same: allocated / request | 38,234 B | 32,603 B (−14.7 %) |
| `sub`: allocated / notification | 126 B | 121 B (−4.0 %) |
**Reading the CPU numbers.** Every item lowers the allocation per
request by a deterministic amount, and the savings add up (the six items
alone sum to −42.1 % against −42.9 % together). CPU per request follows
only partly: each item alone changes it within the run-to-run noise (±3
%); all six together lower it by 3–10 %, with the min..max ranges
separated in the pinned plain async and the `CustomNodeManager2`
encrypted runs and in `read --nodes 1` with 200 sessions. With Server GC
on 4 cores, garbage collection is a small share of the CPU, so 40 %
fewer bytes buy a few percent of CPU. At 24 cores throughput and CPU per
request are dominated by where the scheduler places the threads (Zen 5
and Zen 5c cores) and do not resolve a change of this size.
Allocation trace (o6read 10 × 100, first `Opc.Ua` frame): gone are the
`ResponseHeader` from `ServerBase.CreateResponse`, `Dictionary<NodeId,
NodeState>` (`AsyncCustomNodeManager.ReadAsync`), one of two
`NodeHandle`s, `Variant[]`/`uint[]` (permission attributes),
`List<DataValue>`/`List<DiagnosticInfo>`/`DiagnosticInfo[]`,
`ArrayOf<ExtensionObject>` (`Variant.Copy`), `RolePermissionType[]`,
`SecureChannelContext`, `PendingAdmission`, `System.Action`,
`RequestExecutionScope`, the `DequeueAsync` state machine box,
`MemoryStream`/`BinaryReader` of the decoder, `ArraySegmentStream`,
`BinaryWriter` and one `BufferCollection`.
## Changes
**S1: one `ResponseHeader` per response.** The generated response
constructors already create a default `ResponseHeader`; the services
replaced it with the one `ServerBase.CreateResponse` allocated. The
services that construct their response now offer its default header, and
the base `CreateResponse(RequestHeader, StringTable)` fills it. The
offer goes through a field of the thread, so the protected virtual keeps
its signature: an override that does not call the base returns its own
header as before, and a re-entrant call never gets the outer offer. The
services that receive their response from the subscription manager keep
the previous path. The third `ResponseHeader` in the profile is the
generated `Reuse()` resetting the response after it was sent. It stays:
`LeasedPublishResponse` releases its notification lease there, and the
reset is generated code.
**S2: a single-node Read without collections.**
- The dispatcher fills arrays instead of lists that were copied into the
response (the node managers fill them by index), and allocates the
operation diagnostics only for the first one.
- `AsyncCustomNodeManager.ReadAsync` creates its per-request node cache
only for a request with several nodes, or when a node must be validated.
- The permission check already resolves every node through
`GetManagerHandleAsync`, whose handle "does not require the NodeId to be
validated again". The Read service passes that handle on in
`ReadValueId.Handle` when it is an in-memory node of an
`AsyncCustomNodeManager` that was validated when it was returned, and
the node manager reads through it instead of looking the node up and
allocating a second handle. A handle passed on for an earlier read of
the same `ReadValueId` is cleared.
- The permission check without an attribute cache reads the three
permission attributes into arrays of the thread.
**S3: no copy of empty arrays.** `Variant.Copy` deep-copies arrays of
ExtensionObjects, DataValues and Variants because the caller can change
their elements. An empty array has no element to change but was copied
into a new boxed empty array. The Read service copies the namespace's
DefaultRolePermissions and DefaultUserRolePermissions on every
permission check (the variables' `CopyOnRead` policy); they are empty
unless roles are configured. `TryGetStructure` of an empty array returns
the empty array instead of a new one. Non-empty arrays, scalars and
matrices are copied as before.
**S4: one `SecureChannelContext` per channel token.**
`TcpTransportListener.OnRequestReceived` created a context per request,
although it only holds values that stay the same for the life of a
token. The channel keeps the last context with the values it was created
from and returns it while they are the same references; a renewed token
(new thumbprint, rotated certificate) or a transport reconnected to the
channel gets a new one. The isolation provider (#4787) and the session
binding check compare contexts by value.
**S5: fewer bookkeeping objects per request.**
- A request inside its service dispatch scope, which is every request
the server dispatches, needs no `RequestExecutionScope`: its
`OperationContext` completes the request itself, exactly once, when it
is disposed.
- `FairRequestQueue.TryEnqueue` owns the unpublished entry in a local
instead of a `PendingAdmission` wrapper, and registers the entry's
cancellation with a static callback instead of a delegate per request.
- `DequeueAsync` pools its state machine on .NET.
**S6: fewer codec objects per message.** Encoding a message is
synchronous, so a thread encodes one message at a time. The decoder and
the encoder stay immutable: every message gets new ones (see the
review).
- `EncodeSymmetricMessage` writes the body to the `ArraySegmentStream`
of the thread, reset per message, through a new `BinaryEncoder` that
borrows the `BinaryWriter` the thread keeps over that stream (closing or
disposing such an encoder flushes the writer but leaves it and the
stream open). The stream is given back once it handed its buffers over;
a body that fails to encode releases the stream's buffers, and the
stream is not reused. The stream is per thread, not per channel: since
#4782 the producers encode the responses of a channel concurrently and
only sealing runs in the writer.
- A response (client) in one chunk is decoded from that chunk's buffer,
as the server decodes requests; the client used a stream over the chunk
list for every response.
- A `BinaryDecoder` over a buffer creates its `MemoryStream` and
`BinaryReader` only when `BaseStream` exposes the stream, and reports
`Position` without exposing it. `DecodeMessage` reads `Position`, which
exposed the stream for every message and made every later read
synchronize its position with it.
- `ArraySegmentStream.GetBuffers` hands over the stream's own collection
instead of copying it; a message in one chunk is reassembled into a
collection sized for one.
### Not done
- **Skipping the reset of a sent response** (the third
`ResponseHeader`): `LeasedPublishResponse` releases its notification
lease in `Reuse()`.
- **Pooling `RequestLifetime`, `OperationContext` and
`EndpointIncomingRequest`:** they leave the stack. `RequestLifetime` is
public and handed to every service handler, and its token to node
managers. `EndpointIncomingRequest` is handed to the overridable
`ScheduleIncomingRequest`.
- **Pooling the fair queue `Entry`:** its cancellation registration and
the stop path can still reach it after it was released.
- **A struct token for the isolation lease:** leases are returned as
`IDisposable` through `IServerResourceIsolationProvider.TryAcquire`.
- **Reading the permission defaults without a copy when roles are
configured:** not measurable with the o6 server, which configures none.
## Behaviour notes
- **S1:** an override of `ServerBase.CreateResponse(RequestHeader,
StringTable)` that calls the base gets the response's default header
instead of a new one, the header the response carried anyway.
- **S2:**
- The node managers receive the Read result lists as arrays (`IList<T>`,
fixed size). The lists were pre-filled per item; adding to them was
never part of the contract.
- `ReadValueId.Handle` of a Read request holds the passed-on
`NodeHandle` during the call.
- **S4:** the requests of one token share one `SecureChannelContext`.
`UpstreamIdentity` has a public setter; the TCP transport never sets it,
but application code that set it on the context of a TCP request would
now change it for the token's later requests as well.
- **S6:**
- Each thread that encodes channel messages keeps one stream and writer
(a few hundred bytes), with a reference to the buffer manager of the
last channel it served.
- `BinaryDecoder.Position` of a buffer decoder no longer exposes
`BaseStream`.
## Testing
- **New tests:**
- S1, `StandardServerResponseStringTableTests` and
`ReferenceServerTests`:
- the offered header is filled with every field (timestamp, request
handle, service result, no diagnostics, string table);
- an override without the base keeps its own header;
- an override with the base fills the offered one;
- a re-entrant response never shares it;
- Read, Write and Browse responses keep every header field;
- a failed Read throws its status.
- S2, `AsyncCustomNodeManagerTests.ReadRouting` (all three node manager
fixtures):
- a single-node read uses the handle of the validation and returns what
a multi-node read returns;
- a handle passed on for an earlier read is not reused (another node,
removed node, no session);
- operation diagnostics keep one entry per node and are absent when not
requested.
- S3, `VariantCoverageTests`: empty arrays of each kind are shared; a
null array stays null; `TryGetStructure` of an empty, a null and a
one-element array.
- S4, `TcpListenerChannelTests`: the context is shared until the
thumbprint or the transport changes.
- S5, `RequestManagerTests`:
- an attached request completes once, however often its context is
disposed;
- the ambient request id is restored outside a dispatch scope;
- a stress test of attach, double dispose from two threads, cancellation
and drains.
- S6:
- `BinaryEncoderTests`: encoders borrowing one writer encode like new
encoders, and leave the writer and the stream open; null arguments;
- `BinaryDecoderTests`: `BaseStream` and `Position` of a buffer decoder;
range checks;
- `ArraySegmentStreamTests`: `GetBuffers` hands over and the stream
continues; a read stream still returns a copy; `Reset` and
`ReleaseBuffers`.
- **Run locally (net10.0, all pass):** Opc.Ua.Types.Tests,
Opc.Ua.Core.Tests, Opc.Ua.Core.Encoders.Tests, Opc.Ua.Server.Tests,
Opc.Ua.Client.Tests, Opc.Ua.Sessions.Tests, Opc.Ua.Subscriptions.Tests,
Opc.Ua.Redundancy.Server.Tests, Opc.Ua.Redundancy.Client.Tests,
Opc.Ua.Stress.Tests Contract + Integration. net48 builds.
- **Measured with:** `perf/ServerLoadHarness` scenarios `o6read` (o6
harness, not part of this PR), `read`, `browse`, `sub`.
🤖 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).
- Modern developer surface — first-class
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.
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 stack also includes a large collection of platform-independent sample applications that turn its core services and companion models into runnable 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 small residual manual patterns. The skill knows which sub-doc to load for each symptom so it stays context-efficient.
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.