パフォーマンスチューニング

レンダリングとメモリの最適化

Doconut のリソースプロファイルは、render DPI、what stays cached、how long sessions live の 3 つに支配されています。このガイドでは、インパクトの順にレバーを説明します。

解像度 — 最大のレバー

ImageResolution (25–300 DPI) はレンダー時間と画像サイズの両方を左右します。ほとんどのフォーマットはデフォルトで200 DPIです；画像とPSDはデフォルトで100です。

csharp
// ドキュメントリストのプレビューは印刷品質を必要としません
var token = await viewer.OpenDocumentAsync(path, new PdfConfig { ImageResolution = 100 });

DPI を半分にすると、ページあたりのピクセル数は約4分の1になり、レンダーが速くなり、転送が小さくなり、キャッシュメモリも減ります。ズームが多用されるケース（CAD、エンジニアリング図面）では 250–300 DPI を確保してください。

埋め込み画像が多い PDF では、PdfConfig がより細かい設定を提供します：CompressImages と CompressQuality、ResizeImages と ResizeResolution、そして CompressFast。単純な画像の場合は、ImageConfig.MaxImagePixelSize（デフォルト 3000 ピクセル）が出力サイズを上限します。

ページキャッシュ — メモリ vs. 再レンダー

BaseConfig.CachePages（デフォルトは true）は、セッションの存続期間中、レンダーされたすべてのページをメモリに保持します。インタラクティブな閲覧には適切なデフォルトで、ユーザーは前後にスクロールできます。以下の場合はオフにしてください：

  • ドキュメントが非常に大きく、最初から最後まで一度だけ閲覧する場合、
  • 多数の同時セッションがキャッシュページを増幅させる場合、
  • RAM を保持するよりも、ビューごとに CPU コストを支払う方が好ましい場合。
csharp
var token = await viewer.OpenDocumentAsync(path, new PdfConfig { CachePages = false });

クライアント側では、ViewerConfig.CacheEnabled = true により、ブラウザのメモリに次のページ画像の小さなウィンドウを事前読み込みします。これはビュー単位のプリフェッチキャッシュであり、永続的な localStorage ではありません。

セッション — 見えないメモリ

開かれた各セッションは、解析されたドキュメントモデルと（CachePages が有効な場合）そのレンダーされたページを保持し、スライディング TimeOut（デフォルト 60 分）が 最後のリクエストから 経過するまで維持されます。この状態を管理するための2つの習慣は次のとおりです：

  • 完了したら閉じる。 viewer.CloseDocument(token) はアイドルウィンドウを待たずにエンジンを即座に解放します。
  • タイムアウトを適切に設定する。 ユーザーが2分程度閲覧するプレビューには1時間のセッションは不要です：
csharp
var token = await viewer.OpenDocumentAsync(path, new DocOptions { TimeOut = 10 });

トレードオフを覚えておいてください：期限切れになるとウィジェットは Document session not found. Please re-open document. と表示します — 実際の閲覧セッションに合ったタイムアウトを選択してください。

フォーマット固有のスイッチ

  • Excel：MemoryOptimizationPreference は デフォルトでオン であり、非常に大きなブックのレンダー時のメモリ使用量を削減します — オンのままにするか、メモリを犠牲にしてわずかな速度向上を望む場合は false に設定してください；SheetNames / PrintArea は重要な部分だけのレンダーに制限します。
  • リダイレクトモードは事前コストがかかります：DefaultRender = false はオープン時に 全体 のドキュメントを PDF に変換します。これによりネイティブなテキスト検索が可能になりますが、500 ページのドキュメントではオープン呼び出しがその変換を伴います — 反射的に有効にしないでください。
  • Linux/Docker 上の Word/PPT：フォントが欠如すると、フォールバックの探索が遅くなり、メトリクスが正しくありません；FontFolders をフォントが格納されたディレクトリに設定してください。
  • Linux/macOS 上のプレゼンテーション：PPT/PPTX/PPS/POT/ODP ファイルは開くことができますが、現在のプレゼンテーションエンジンでレンダーするにはネイティブ libgdiplus とランタイムスイッチ System.Drawing.EnableUnixSupport=true が必要です。他のフォーマットファミリーは通常のクロスプラットフォームレンダリングパスを使用します。

クライアント側戦略

  • LargeDoc = true — 非常に大きなドキュメント向けの遅延ロード戦略；ユーザーがページに近づくとロードされます。
  • AutoLoad = false（デフォルト） — 実際に View(token) を呼び出すまでレンダーしません。
  • ShowThumbs = false — 単一ページや埋め込みプレビューの場合、サムネイル生成/リクエストをスキップします。
  • FixedZoom を有効にすると、自由形式のズーム変更を回避できます；C# の ViewerConfig をマッピングする際は、小画面向けに FixedZoomPercentMobile（C# デフォルト 75）を調整してください。

起動は一度だけ、リクエストごとではなく

Encoding.RegisterProvider(CodePagesEncodingProvider.Instance) は Program.cs に配置すべきです — リクエストごとにエンコーディングを登録すると無駄な作業になります；忘れるとレガシーなコードページドキュメントが壊れます。

ノード間で作業を分散

上記はすべて、オンデマンドで単一ノードのレンダーを調整するものです。単一ノードが負荷を吸収できない場合、次のレバーは大きなダイヤルではなく、ドキュメントのアーティファクトを一度共有ストレージに公開し、すべてのノードがそれを提供することです。これによりコストモデルが変わります：レンダーはセッションごとではなくドキュメントごとに一度だけ行われ、ページリクエストはファイル読み取りになります。参照: 分散デプロイ。

チューニングチェックリスト

  1. UX が受け入れられる最小の ImageResolution を設定します。
  2. インタラクティブな閲覧では CachePages をオンに保ち、ワンパスまたは高同時性シナリオではオフにします。
  3. セッションを明示的に閉じ、使用がバースト的な場合は TimeOut を短くします。
  4. 大きなドキュメントではクライアント側で LargeDoc とデフォルトの AutoLoad = false を使用します。
  5. テキストを含む PDF 投影が必要な場合にのみ DefaultRender = false を使用します。

このページは役に立ちましたか？