Performance-Optimierung

Rendern und Speicher optimieren

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 der Reihenfolge ihrer Wirkung auf.

Auflösung — die wichtigste Stellschraube

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

csharp
// A document list preview doesn't need print quality
var token = await viewer.OpenDocumentAsync(path, new PdfConfig { ImageResolution = 100 });

Eine Halbierung der DPI reduziert die Pixelanzahl pro Seite etwa um ein Viertel — schnellere Renderings, kleinere Übertragungen, weniger Cache‑Speicher. Reservieren Sie 250–300 DPI für stark zoom‑intensive Anwendungsfälle (CAD, technische Zeichnungen).

Für PDFs mit vielen eingebetteten Bildern bietet PdfConfig feinere Einstellmöglichkeiten: 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) speichert jede gerenderte Seite im Speicher für die gesamte Sitzungsdauer. Das ist die richtige Voreinstellung für interaktives Betrachten — Nutzer scrollen vor‑ und zurück. Schalten Sie es ab, wenn:

  • Dokumente riesig sind und nur einmal von vorne bis hinten angesehen werden,
  • viele gleichzeitige Sitzungen die gecachten Seiten vervielfachen würden,
  • Sie lieber CPU‑Kosten pro Ansicht tragen möchten, anstatt RAM zu belegen.
csharp
var token = await viewer.OpenDocumentAsync(path, new PdfConfig { CachePages = false });

Auf dem Client pre‑lädt ViewerConfig.CacheEnabled = true ein kleines, sich bewegendes Fenster kommender Seitenbilder im Browser‑Speicher. Es handelt sich um einen per‑Ansicht‑Prefetch‑Cache, nicht um persistenten localStorage.

Sitzungen — der Speicher, den Sie nicht sehen

Jede offene Sitzung hält das geparste Dokumentmodell sowie (bei aktivem CachePages) die gerenderten Seiten, bis das gleitende TimeOut (Standard 60 Minuten) seit der letzten Anforderung abläuft. Zwei Gewohnheiten halten das im Griff:

  • Schließen Sie, was Sie nicht mehr benötigen. viewer.CloseDocument(token) gibt die Engine sofort frei, anstatt das Leerlauf‑Fenster abzuwarten.
  • Passen Sie die Timeout‑Dauer an. Eine Vorschau, die Nutzer nur zwei Minuten betrachten, benötigt keine einstündige Sitzung:
csharp
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 realen Lese‑Sitzungen 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 gegen einen kleinen Geschwindigkeitszuwachs eintauschen wollen; SheetNames / PrintArea beschränken das Rendern auf das Wesentliche.
  • Redirect‑Modus hat Vorlaufkosten: DefaultRender = false konvertiert das gesamte Dokument beim Öffnen zu PDF. Das ermöglicht native textbasierte Suche, aber bei einem 500‑Seiten‑Dokument trägt der Öffnungsaufruf diese Konvertierung — nicht reflexartig aktivieren.
  • Word/PPT unter Linux/Docker: Fehlende Schriften führen zu langsamen Fallback‑Abfragen und falschen Metriken; verweisen Sie FontFolders auf ein Verzeichnis mit Ihren Schriften.
  • Präsentationen unter Linux/macOS: PPT/PPTX/PPS/POT/ODP‑Dateien können geöffnet werden, aber das Rendering mit der aktuellen Präsentations‑Engine erfordert das native libgdiplus und den Laufzeit‑Schalter System.Drawing.EnableUnixSupport=true. Andere Formatfamilien nutzen den normalen plattformübergreifenden Rendering‑Pfad.

Client‑seitige Strategien

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

Einmal starten, nicht pro Anfrage

Encoding.RegisterProvider(CodePagesEncodingProvider.Instance) gehört in Program.cs — das Registrieren von Encodings pro Anfrage ist unnötiger Aufwand; das vollständige Vergessen führt bei Legacy‑Code‑Page‑Dokumenten zu Fehlern.

Arbeit über Knoten verteilen

Alles oben optimiert das Rendering eines einzelnen Knotens auf Abruf. Wenn ein einzelner Knoten die Last nicht tragen kann, ist die nächste Stellschraube nicht ein größerer Regler — sondern das einmalige Veröffentlichen der Dokument‑Artefakte in gemeinsamem Speicher, sodass jeder Knoten sie bereitstellen kann. Das ändert das Kostenmodell: Rendering erfolgt einmal pro Dokument statt einmal pro Sitzung, und Seiten‑Anfragen werden zu Dateizugriffen. Siehe Verteilte Bereitstellungen.

Eine Optimierungs‑Checkliste

  1. Setzen Sie die niedrigste ImageResolution, die Ihre 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 + Standard‑AutoLoad = false auf dem Client für große Dokumente.
  5. Nutzen Sie DefaultRender = false nur, wenn Sie eine textbasierte PDF‑Projection benötigen.

War diese Seite hilfreich?