[Audit KB-4] Synchrones Parsen/Validieren im MLLP-Lesepfad + 2–3× String-Duplikat-Footprint

[Pappet]

Schweregrad

Kritisch — wahrscheinlichster Produktions-Crash beim MDM-Lastprofil (lt. CLAUDE.md das Zielprofil).

Problem

(a) Synchroner Hot-Path: parse_message führt fünf Pässe synchron aus (src/hl7/parser.rs:5-15), bevor store.insert aufgerufen wird (src/mllp.rs:217). Die Verbindung kann den nächsten Frame erst danach lesen.

(b) Speicher-Multiplikator: Pro Feld wird mehrfach derselbe Inhalt gehalten:

• value (String) — src/hl7/parser.rs:213
• components — jede Komponente erneut als eigener String — src/hl7/parser.rs:207-210
• description — geklonter Dictionary-String pro Feld — src/dictionary.rs:71-74

Eine 5-MB-Base64-OBX-Zeile liegt als value (5 MB) und components[0] (5 MB) und in raw → ~3× raw. estimated_bytes zählt das korrekt mit, aber zusammen mit KB-2/KB-3 läuft der nominelle 512-MB-Deckel real deutlich früher gegen physischen RAM.

Lösungsvorschlag

• Dictionary-Beschreibungen nicht pro Feld klonen — &'static str / Index in das OnceLock-Dictionary referenzieren statt String-Klone.
• components lazy / Cow statt eager Vec<String>; besonders für Single-Component-Felder kein Klon.
• Validierung/Dictionary-Injektion ggf. aus dem Lesepfad in einen separaten Task verlagern.

Teil des Vibecoding-Code-Audits (KB-4).

[Pappet]

Root Cause Analysis

Zwei separate Performance-Probleme im MLLP-Hot-Path.

Problem A: Synchroner 5-Pass-Parse vor store.insert

handle_connection (mllp.rs:128) liest einen MLLP-Frame, ruft dann auf:

parse_message()         → parser.rs:5 — 5 synchrone Pässe
  ├─ parse_structure()  — Segment-Split, Delimiter-Extraktion
  ├─ enrich_msh()       — MSH-Feld-Extraktion (O(segs))
  ├─ enrich_pid()       — PID-Feld-Extraktion
  ├─ inject_descriptions()  — dictionary.rs:65 — O(segs x fields)
  ├─ annotate_message_type() — message_types Lookup
  └─ validate()         — validation.rs — O(segs x fields)
store.insert(msg)       → store.rs:96

Der gesamte Parse + Validate läuft synchron auf dem Tokio-Task dieser einen Verbindung. Der Task kann keinen weiteren MLLP-Frame lesen, bis alles durch ist. Bei einer 5-MB-MDM-Base64:

Schritt	Geschätzte Kosten
parse_structure	String-Split (O(bytes))
enrich_msh	5x lineare Suche in O(fields)
enrich_pid	2x lineare Suche in O(fields)
inject_descriptions	Dictionary-Lookup pro Feld (HashMap) + clone
validate	Segment-Prüfung, Feld-Prüfung, Datentyp-Prüfung
Gesamt	2–5 ms pro MDM — kein Problem für eine Verbindung

Das eigentliche Problem: Unter Last mit mehreren parallelen Verbindungen (Orchestra schickt oft 10+/s) blockiert jede parse_message-Instanz ihren Connection-Task. Der kritische Punkt: store.insert() ist async und gibt den Task an dieser Stelle zurück an den Scheduler. Alles davor ist CPU-gebunden.

Problem B: 2–3x String-Duplikation

Für jedes Feld jeder Nachricht wird mehrfach derselbe Inhalt alloziert:

1. value vs components (parser.rs:207–214)

let components: Vec<String> = part
    .split(delimiters.component)
    .map(|c| c.to_string())   // (1) Jede Komponente = eigener Heap-String
    .collect();

fields.push(Hl7Field {
    value: part.to_string(),   // (2) Noch ein Heap-String — Duplikat
    components,                // (1) bereits allokiert
    description: None,
});

Für ein OBX-5-Feld mit 5 MB Base64: value = 5 MB, components[0] = 5 MB. → 10 MB für ein Feld.

2. description-Klone (dictionary.rs:71–74)

for field in segment.fields.iter_mut() {
    if let Some(field_def) = seg_def.field_by_seq(field.index) {
        field.description = Some(field_def.desc.clone());  // Klon pro Feld
    }
}

Das Dictionary lebt static. Jeder description-String wird aus dem OnceLock pro Feld frisch geklont. Bei 10.000 Nachrichten x 15 Feldern = 150.000 String::clone()-Aufrufe.

3. Segment-Raw (parser.rs:241)

Hl7Segment { raw: raw.to_string(), ... }

Der gesamte Segment-String liegt bereits in Hl7Message.raw. segments[i].raw ist ein erneuter Klon.

Heap-Multiplikator (Summe für eine OBX-MDM)

Quelle	Größe	Multiplikator
msg.raw	5,1 MB	1x
OBX-5 value	5 MB	~1x
OBX-5 components[0]	5 MB	~1x
OBX-5 description	~50 B	vernachlässigbar
OBX raw (Segment)	~5,02 MB	~1x
Andere Felder	~10 KB	vernachlässigbar
Gesamt Heap	~15 MB	~3x raw

---

Lösungsvorschlag

Fix A1: Validation aus dem MLLP-Hot-Path entfernen

Die Validierung ist ein reines UI-Feature — sie produziert Warnungen für die Detailansicht. Sie muss nicht vor store.insert laufen.

Ansatz: parse_message auf die ersten 4 Pässe reduzieren. Validation als asynchrone Nachbearbeitung:

async fn insert_and_validate(&self, msg: Hl7Message) {
    let id = msg.id.clone();
    self.insert(msg).await;
    tokio::spawn(async move {
        if let Some(arc) = store.get_by_id(&id).await {
            let mut inner = store.inner.write().await;
            if let Some(arc) = inner.messages.get_mut(&id) {
                let msg_ref = Arc::make_mut(arc);
                msg_ref.validation_warnings = validate(msg_ref);
                // broadcast Summary update
            }
        }
    });
}

Trade-off: Nach dem initialen Insert hat die Nachricht kurz validation_warnings = []. Die UI zeigt sie als "valid" an, bis die Background-Task durch ist. Bei 250-ms-Flush-Intervall im Frontend fällt das kaum auf.

Fix B1: Dictionary-Descriptions als &'static str

Hl7Field.description: Option<String> → Hl7Field.description: Option<&'static str>

Da das Dictionary in einem OnceLock lebt, sind die Strings static. Die Clone-Kosten entfallen vollständig:

// dictionary.rs
pub fn inject_descriptions(segments: &mut [Hl7Segment]) {
    let dict = get_v251();
    for segment in segments.iter_mut() {
        if let Some(seg_def) = dict.segments.get(&segment.name) {
            segment.description = Some(&seg_def.desc);      // static str
            for field in segment.fields.iter_mut() {
                if let Some(field_def) = seg_def.field_by_seq(field.index) {
                    field.description = Some(&field_def.desc); // Kein Klon mehr
                }
            }
        }
    }
}

Kein neuer Crate, keine Lifetime-Parameter — Serde serialisiert &'static str wie String.

Fix B2: Lazy/Client-side Components

components aus Hl7Field entfernen und client-seitig im Frontend splitten:

// In render.js buildFieldRow — statt f.components zu verwenden:
const components = f.value.split('^');

Das eliminiert die gesamte eager Component-Allocation auf dem Server. Spart bei 10.000 Nachrichten x 15 Feldern x 1 KB = 150 MB Heap.

Alternative: components als berechnetes Feld:

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct Hl7Field {
    pub index: usize,
    pub value: String,
    #[serde(skip_serializing_if = "Vec::is_empty", default)]
    pub components: Vec<String>,  // bleibt, wird nur bei >1 Komponente befüllt
    pub description: Option<&'static str>,
}

Im Parser: nur bei mehrteiligen Komponenten splitten. Bei Single-Component (häufigster Fall, besonders OBX Base64): components = vec![].

---

Implementierungs-Reihenfolge

1. &'static str für Descriptions (types.rs + dictionary.rs) — kein Crate, kein Lifetime-Parameter, sofort wirksam.
2. Client-side Components (render.js) — eliminiert größten Heap-Verbraucher.
3. Validation async (mllp.rs + store.rs) — verschiebt CPU-Last aus dem Connection-Task.
4. Segment-Raw-Deduplizierung — erfordert Zero-Copy-Refactoring (gegen Constraints) → zurückgestellt.

---

Risiken / Nebenwirkungen

• &'static str ist rückwärtskompatibel: Serde serialisiert &'static str identisch zu String. Kein Frontend-Change nötig.
• Lazy Components ändern die API: Wenn externes Tool components im JSON erwartet, muss es jetzt selbst splitten. Da dies eine interne API ist (einziges Frontend = Harux SPA), akzeptabel.
• Async Validation: Die Race-Condition zwischen async validation und UI-Refresh. WebSocket-Broadcast nach insert liefert initialen Render (ohne Warnings). Nach Validierung zweiter Broadcast mit aktualisiertem Summary. Frontend patcht via patchRow.
• Segment-Raw bleibt: Der Klon von Segment-Text in Hl7Segment.raw ist ohne Zero-Copy nicht eliminierbar. Akzeptabel unter den gegebenen Constraints.