Performance-Optimierung

Das Ressourcenprofil von Doconut wird von drei Dingen dominiert: Render-DPI, was im Cache bleibt und wie lange Sitzungen leben. Dieser Leitfaden führt die Stellschrauben in Reihenfolge ihrer Wirkung auf.

Auflösung — die stärkste Stellschraube

ImageResolution (25–300 DPI) beeinflusst sowohl die Renderzeit als auch die Bildgröße. Die meisten Formate haben standardmäßig 200 DPI; Bilder und PSD haben standardmäßig 100.

// Eine Dokumentenlisten-Vorschau benötigt keine Druckqualität
var token = await viewer.OpenDocumentAsync(path, new PdfConfig { ImageResolution = 100 });

Eine Halbierung des DPI reduziert ungefähr um das Vierfache die Pixelanzahl pro Seite — schnellere Renderings, kleinere Übertragungen, weniger Cache-Speicher. Reservieren Sie 250–300 DPI für stark gezoomte Anwendungsfälle (CAD, technische Zeichnungen).

Für PDFs mit vielen eingebetteten Bildern fügt PdfConfig feinere Einstellungen hinzu: CompressImages + CompressQuality, ResizeImages + ResizeResolution und CompressFast. Für reine Bilder begrenzt ImageConfig.MaxImagePixelSize (Standard 3000 px) die Ausgabengröße.

Seiten-Caching — Speicher vs. Neu-Rendern

BaseConfig.CachePages (Standard true) hält jede gerenderte Seite im Speicher für die gesamte Sitzungsdauer. Das ist die richtige Standardeinstellung für interaktives Betrachten — Benutzer scrollen vor und zurück. Deaktivieren Sie es, wenn:

• Dokumente sind riesig und werden einmal von vorne bis hinten betrachtet,
• Viele gleichzeitige Sitzungen würden die zwischengespeicherten Seiten vervielfachen,
• Sie lieber CPU pro Ansicht bezahlen möchten, anstatt RAM zu belegen.

var token = await viewer.OpenDocumentAsync(path, new PdfConfig { CachePages = false });

Auf dem Client lädt ViewerConfig.CacheEnabled = true ein kleines, sich bewegendes Fenster der kommenden Seitenbilder im Browser‑Speicher vor. Es ist ein per‑View‑Prefetch‑Cache, kein permanenter localStorage.

Sitzungen — der Speicher, den Sie nicht sehen

Jede offene Sitzung hält das geparste Dokumentenmodell plus (mit CachePages) seine gerenderten Seiten, bis das gleitende TimeOut (Standard 60 Minuten) seit der letzten Anforderung abläuft. Zwei Gewohnheiten halten dies unter Kontrolle:

• Schließen Sie, was Sie fertig sind. viewer.CloseDocument(token) gibt die Engine sofort frei, anstatt das Leerlauffenster abzuwarten.
• Passen Sie das Timeout an. Eine Vorschau, die Benutzer für zwei Minuten ansehen, benötigt keine einstündige Sitzung:

var token = await viewer.OpenDocumentAsync(path, new DocOptions { TimeOut = 10 });

Beachten Sie den Kompromiss: Nach Ablauf zeigt das Widget Document session not found. Please re-open document. — wählen Sie ein Timeout, das zu echten Lesesitzungen passt.

Format‑spezifische Schalter

• Excel: MemoryOptimizationPreference ist standardmäßig aktiviert und reduziert den Speicherverbrauch beim Rendern sehr großer Arbeitsmappen — lassen Sie es aktiviert, oder setzen Sie es auf false, wenn Sie Speicher für einen kleinen Geschwindigkeitsgewinn tauschen möchten; SheetNames / PrintArea beschränken das Rendering auf das Wesentliche.
• Der Weiterleitungsmodus hat Vorlaufkosten: DefaultRender = false konvertiert das gesamte Dokument beim Öffnen in PDF. Das ermöglicht native textbasierte Suche, aber bei einem 500‑Seiten‑Dokument trägt der Öffnungsaufruf diese Konvertierung — aktivieren Sie es nicht reflexartig.
• Word/PowerPoint auf einem Server ohne die Schriften der Dokumente: Ein Windows‑Server ohne Office hat deutlich weniger Schriften als ein Entwicklungsrechner. Fehlende Schriften verursachen langsames Fallback‑Probing und falsche Metriken; installieren Sie die Schriften oder verweisen Sie FontFolders auf einen Ordner, der sie enthält.

Client‑seitige Strategien

• LargeDoc = true — Lazy‑Load‑Strategie für sehr große Dokumente; Seiten werden geladen, wenn der Benutzer sich ihnen nähert.
• AutoLoad = false (Standard) — nicht rendern, bis Sie tatsächlich View(token) aufrufen.
• ShowThumbs = false — überspringt die Thumbnail‑Erstellung/-Anfragen für einseitige oder eingebettete Vorschauen.
• Das Aktivieren von FixedZoom verhindert freie Zoom‑Änderungen; wenn Sie ein C# ViewerConfig zuordnen, stellen Sie FixedZoomPercentMobile (C#‑Standard 75) für kleine Bildschirme ein.

Einmal starten, nicht pro Anfrage

Encoding.RegisterProvider(CodePagesEncodingProvider.Instance) gehört zu Application_Start, neben DoconutHost.Initialize — das Registrieren von Codierungen pro Anfrage ist unnötige Arbeit; das komplette Vergessen bricht Legacy‑Code‑Page‑Dokumente.

Das erste Dokument nach einem Start

Doconut lädt seine Dokument‑Engines beim ersten Öffnen eines Dokuments in einer Anwendung — nach dem Start des Pools, nach jedem Recycle und in jeder neuen Anwendungsdomäne. Dieses erste Öffnen ist langsamer als die folgenden, und Echtzeit‑Antivirus kann es noch viel langsamer machen: Die Engines werden aus dem Speicher geladen, und Microsoft Defender scannt den Code beim Laden. Ein Ordner‑Ausschluss hilft nicht, weil keine Datei beteiligt ist.

Gemessen auf einer 4‑Kern‑Windows‑Server‑2022‑Maschine beim Öffnen eines zweiseitigen Word‑Dokuments:

Zahlen Sie einmal, bevor Ihre Nutzer es tun:

• Halten Sie den Worker‑Prozess am Leben: Setzen Sie den Start‑Modus des Anwendungspools auf AlwaysRunning und erhöhen oder deaktivieren Sie dessen Leerlauf‑Timeout, damit eine ruhige Nacht die Engines nicht entlädt.
• Wärmen Sie ihn beim Start auf: Aktivieren Sie IIS Application Initialization (preloadEnabled="true" auf der Site) und verweisen Sie dessen initializationPage auf eine Ihrer Seiten, die ein kleines Dokument öffnet. Der erste echte Nutzer findet dann die Engines bereits geladen.
• Geben Sie der ersten Anfrage Zeit: Ein Load‑Balancer‑Health‑Check oder ein vorgelagerter Proxy mit kurzem Timeout kann bei einem Kaltstart, der erfolgreich gewesen wäre, abbrechen.

Ob Sie die Antivirus‑Einstellungen auf einem Server ändern, ist eine Entscheidung Ihres Sicherheitsteams; das oben beschriebene Warm‑up funktioniert ohne diese Änderung.

Der Anwendungspool

Auf einem einzelnen Server leben Dokument‑Sitzungen und zwischengespeicherte Seiten im Worker‑Prozess. Jeder Anwendungspool‑Recycle — der geplante, eine Änderung an Web.config oder das Leerlauf‑Timeout des Pools (standardmäßig 20 Minuten in IIS) — löscht sie alle, und offene Viewer zeigen dann Document session not found. Please re-open document.

• Stimmen Sie das Leerlauf‑Timeout und den Recycling‑Zeitplan des Pools mit der tatsächlichen Lesezeit Ihrer Nutzer ab, oder seien Sie bereit, Dokumente nach einem Recycle erneut zu öffnen.
• Führen Sie den Pool als 64‑Bit‑Prozess aus (lassen Sie Enable 32-Bit Applications deaktiviert). Große Dokumente benötigen den Adressraum, den ein 32‑Bit‑Worker‑Prozess nicht hat.
• Ein Web‑Farm speichert Sitzungen in einem gemeinsamen Speicher, sodass ein Recycle auf einem Knoten sie nicht verliert — siehe Sitzungen & Sicherheit.

Eine Optimierungs‑Checkliste

1. Setzen Sie das niedrigste ImageResolution, das Ihr UX akzeptiert.
2. Lassen Sie CachePages für interaktives Betrachten aktiviert; deaktivieren Sie es für Einmal‑Durchläufe oder Szenarien mit hoher Parallelität.
3. Schließen Sie Sitzungen explizit; verkürzen Sie TimeOut, wenn die Nutzung burstartig ist.
4. Verwenden Sie LargeDoc + den StandardAutoLoad = false auf dem Client für große Dokumente.
5. Verwenden Sie DefaultRender = false nur, wenn Sie eine textbasierte PDF‑Projektion benötigen.