Registry-Cache #

Der Registry-Cache ist eine reine Performance-Optimierung für das Lesen aus der SQL-Registry. Er ist für den normalen Anwendungsfall transparent, sollte aber einmal verstanden sein, wenn man viele Registry-Zugriffe hintereinander macht oder auf einem VPN arbeitet.

Zwei Betriebsarten #

EulandaXtools kann die Registry auf zwei Arten lesen:

LegacyStore (ohne Cache) #

flowchart TD L1[Get-EulandaRegistryValue]:::anlegen L2[SQL-Roundtrip
cnf_RegReadString]:::storno L3[(SQL-Registry)]:::store L1 --> L2 --> L3 classDef anlegen fill:#2e86c1,color:#fff,stroke:#1a5276 classDef storno fill:#c0392b,color:#fff,stroke:#7b241c classDef store fill:#566573,color:#fff,stroke:#2c3e50

HiveStore (mit Cache) #

flowchart TD H1[Get-EulandaRegistryValue]:::anlegen H2{Subtree
schon im
Cache?}:::umwandlung H3[aus Hive lesen
0 ms]:::buchen H4[cn_RegBulkRead
einmalig]:::teilstorno H5[(SQL-Registry)]:::store H6[Subtree cachen]:::buchen H1 --> H2 H2 -->|ja| H3 H2 -->|nein| H4 H4 --> H5 H4 --> H6 H6 --> H3 classDef anlegen fill:#2e86c1,color:#fff,stroke:#1a5276 classDef buchen fill:#27ae60,color:#fff,stroke:#196f3d classDef umwandlung fill:#8e44ad,color:#fff,stroke:#5b2c6f classDef teilstorno fill:#e67e22,color:#fff,stroke:#af601a classDef store fill:#566573,color:#fff,stroke:#2c3e50

Modus	Beschreibung
LegacyStore	Jeder `Get-EulandaRegistryValue` führt direkt einen Stored-Proc-Call aus. Kein Cache, kein State in der Session.
HiveStore	Ein kompletter Subtree wird einmal eingelesen und im PowerShell-Prozess als “Hive” gecacht. Folgeabfragen auf Werte in der Hive gehen dann ohne SQL-Roundtrip aus dem Speicher.

Faktor 9 auf VPN. Der HiveStore ist auf VPN-Verbindungen um den Faktor ~9 schneller (Messung 2026 an einem Standard-Szenario mit 15 Value-Reads aus einem Subtree). Das gilt für den Fall, für den er gebaut wurde: EULANDA-Klassik über eine langsame Leitung, wo jeder Roundtrip teuer ist.

Lokal dreht sich das um. Auf einer Verbindung ohne Latenz kostet der Hive mehr, als er spart - er liest einen ganzen Subtree, wo eine einzelne Abfrage gereicht hätte. Gemessen am 07.08.2026, Get-XrestGeoConfig gegen einen lokalen SQL Server (sechs Werte aus einem Subtree):
Modus erster Zugriff fünf weitere
Hive 251 ms 310 ms
Off 108 ms 55 ms
Bemerkenswert ist die zweite Spalte: mit Hive werden die Folgezugriffe nicht billiger, sondern bleiben teuer - der erhoffte Cache-Effekt tritt in diesem Muster gar nicht ein.
Server-Prozesse, die lokal oder im LAN arbeiten, gewinnen dadurch nichts.

Modus	erster Zugriff	fünf weitere
Hive	251 ms	310 ms
Off	108 ms	55 ms

Vorgabe: aus (seit 26.08.2026) #

Der Cache ist aus, solange ihn niemand einschaltet. Bis zum 26.08.2026 war es umgekehrt.

Der Grund ist Erfahrung, nicht Theorie. Die Hive ist dateibasiert und überdauert den Prozess. Ein Wert, der in der Datenbank geändert wurde, blieb im Cache stehen, und die Wirkung war schwer zu deuten:

Ein eingespielter Lizenzblock meldete “erfolgreich”, und das Kaufmodul blieb gesperrt (26.08.2026 auf ancona, Produkt xfacture). Auch ein Neustart half nicht - die Hive liegt auf der Platte.
Eine geänderte Einstellung wirkte erst nach einem Verwerfen, das niemand vermutete.

Dazu die Messung oben: im Server-Muster wird der Zugriff mit Hive nicht schneller, sondern langsamer. Der Nutzen trägt vor allem in der EULANDA-Klassik selbst, wo dieselben Werte hundertfach gelesen werden; die X-Suite liest sie einmal je Vorgang. Dort steht der Ärger in keinem Verhältnis zum Gewinn (CN 26.08.2026).

Steuerung #

Die Umgebungsvariable EULXT_REGCACHE wird beim Modul-Load ausgewertet:

Wert	Effekt
nicht gesetzt, leer, `off`	LegacyStore (immer direkter SQL-Call)
`hive`, `on`, `1`, `true`, `ja`	HiveStore (Cache aktiv)
irgendetwas anderes	LegacyStore - ein Tippfehler schaltet den Cache nicht ein

Zur Laufzeit - die Variable wirkt danach nicht mehr:

Set-EulandaRegistryCacheMode -Mode Hive   # etwa vor einer Messreihe
Set-EulandaRegistryCacheMode -Mode Off

Der aktuelle Modus lässt sich abfragen:

Get-EulandaRegistryCacheMode
# Ergebnis: 'Hive', 'Legacy-Fallback' oder 'Off'

Cache gezielt verwerfen #

Cache wird stale bei externen Schreibzugriffen. Nach einem Schreibvorgang aus der EULANDA-Software oder einem anderen Prozess ist der Cache in der eigenen PowerShell-Session veraltet – die eigene Session weiß nichts von der Änderung. Vor kritischen Lesevorgängen ggf. explizit invalidieren.

# Kompletten Cache verwerfen
Clear-EulandaRegistryCache

# Nur einen Subtree invalidieren
Clear-EulandaRegistryCache -Path '\MODULES\Grundwerte\Xfacture'

Im LegacyStore sind beide Calls ein No-Op (es gibt ja keinen Cache).

Wann relevant? #

Für einzelne Skripte, die Registry nur ein paar Mal anfassen, merkt man den Unterschied nicht. Spürbar wird der Cache in drei Situationen:

Lange Pipelines, die dutzende Registry-Werte aus dem Firmenstamm, aus Plugin-Configs und aus Grundwerten lesen (z.B. Rechnungs-Export, Shopify-Sync) – hier spart der Cache viele Sekunden.
VPN-Verbindungen, bei denen jeder SQL-Roundtrip 50–200 ms kostet.
Unit-Tests gegen eine echte DB, wenn einzelne Tests die Registry verändern und andere Tests denselben Wert danach lesen – hier den Cache am Anfang/Ende explizit invalidieren, sonst liest man veraltete Werte.

Init-Block beim Modul-Laden. Der interne RegStore wird im Normalfall beim ersten Import-Module automatisch initialisiert. In Spezialszenarien (z.B. Modul-Reload mit Import-Module -Force aus Plugin-Ketten) kann Initialize-EulRegStore auch manuell aufgerufen werden, um den Init-Block sicher durchlaufen zu lassen.