Ottimizzazione delle prestazioni

Ottimizza il rendering e la memoria

Il profilo delle risorse di Doconut è dominato da tre elementi: render DPI, cosa rimane nella cache e quanto tempo vivono le sessioni. Questa guida percorre le leve in ordine di impatto.

Risoluzione — la leva più grande

ImageResolution (25–300 DPI) determina sia il tempo di rendering sia la dimensione dell'immagine. La maggior parte dei formati ha come predefinito 200 DPI; le immagini e i PSD hanno come predefinito 100.

csharp
// Un'anteprima dell'elenco dei documenti non richiede la qualità di stampa
var token = await viewer.OpenDocumentAsync(path, new PdfConfig { ImageResolution = 100 });

Ridurre la DPI della metà dimezza approssimativamente il conteggio dei pixel per pagina — rendering più veloce, trasferimenti più piccoli, meno memoria cache. Riserva 250–300 DPI per casi d'uso con molto zoom (CAD, disegni tecnici).

Per i PDF con immagini incorporate pesanti, PdfConfig aggiunge controlli più fini: CompressImages + CompressQuality, ResizeImages + ResizeResolution, e CompressFast. Per le immagini semplici, ImageConfig.MaxImagePixelSize (predefinito 3000 px) limita la dimensione dell'output.

Caching delle pagine — memoria vs. ri-render

BaseConfig.CachePages (predefinito true) mantiene ogni pagina renderizzata in memoria per tutta la durata della sessione. È il valore predefinito corretto per la visualizzazione interattiva — gli utenti scorrono avanti e indietro. Disattivalo quando:

  • i documenti sono enormi e visualizzati una sola volta, dall'inizio alla fine,
  • molte sessioni concorrenti moltiplicherebbero le pagine nella cache,
  • preferisci spendere CPU per visualizzazione piuttosto che mantenere RAM.
csharp
var token = await viewer.OpenDocumentAsync(path, new PdfConfig { CachePages = false });

Sul client, ViewerConfig.CacheEnabled = true precarica una piccola finestra mobile di immagini delle pagine successive nella memoria del browser. È una cache di prefetch per visualizzazione, non una localStorage persistente.

Sessioni — la memoria che non vedi

Tutte le sessioni aperte mantengono il modello del documento analizzato più (con CachePages) le sue pagine renderizzate, fino a quando il TimeOut mobile (predefinito 60 minuti) scade dal momento dell'ultima richiesta. Due abitudini mantengono questo sotto controllo:

  • Chiudi ciò che hai finito. viewer.CloseDocument(token) libera il motore immediatamente invece di attendere la finestra di inattività.
  • Dimensiona correttamente il timeout. Un'anteprima che gli utenti guardano per due minuti non necessita di una sessione di un'ora:
csharp
var token = await viewer.OpenDocumentAsync(path, new DocOptions { TimeOut = 10 });

Ricorda il compromesso: dopo la scadenza il widget mostra Document session not found. Please re-open document. — scegli un timeout che corrisponda alle reali sessioni di lettura.

Interruttori specifici per formato

  • Excel: MemoryOptimizationPreference è attivo per impostazione predefinita e riduce l'impronta di memoria durante il rendering di cartelle di lavoro molto grandi — lascialo attivo, o impostalo a false se vuoi scambiare memoria per un piccolo guadagno di velocità; SheetNames / PrintArea limitano il rendering a ciò che è importante.
  • La modalità di reindirizzamento ha un costo iniziale: DefaultRender = false converte l'intero documento in PDF al momento dell'apertura. Consente la ricerca nativa basata sul testo, ma su un documento di 500 pagine la chiamata di apertura porta con sé quella conversione — non abilitarla automaticamente.
  • Word/PowerPoint su un server senza i font dei documenti: un Windows Server senza Office ha molti meno font rispetto a una macchina di sviluppo. I font mancanti causano una lenta ricerca di fallback e metriche errate; installa i font, o punta FontFolders a una cartella che li contiene.

Strategie lato client

  • LargeDoc = true — strategia di lazy-load per documenti molto grandi; le pagine si caricano man mano che l'utente si avvicina.
  • AutoLoad = false (predefinito) — non renderizzare finché non chiami effettivamente View(token).
  • ShowThumbs = false — salta la generazione/richieste di miniature per anteprime a pagina singola o incorporate.
  • Abilitare FixedZoom evita modifiche di zoom libere; quando mappi un ViewerConfig C#, regola FixedZoomPercentMobile (predefinito C# 75) per schermi piccoli.

Avvio una sola volta, non per richiesta

Encoding.RegisterProvider(CodePagesEncodingProvider.Instance) appartiene a Application_Start, accanto a DoconutHost.Initialize — registrare le codifiche per richiesta è lavoro sprecato; dimenticarlo completamente rompe i documenti legacy basati su code-page.

Il primo documento dopo l'avvio

Doconut carica i suoi motori di documento la prima volta che un documento viene aperto in un'applicazione — dopo l'avvio del pool, dopo ogni riciclo e in ogni nuovo dominio dell'applicazione. Quella prima apertura è più lenta di quelle successive, e l'antivirus in tempo reale può renderla molto più lenta: i motori vengono caricati dalla memoria, e Microsoft Defender scansiona quel codice mentre lo carica. Un'esclusione di cartella non aiuta, perché non è coinvolto alcun file.

Misurato su una macchina Windows Server 2022 a 4 core, aprendo un documento Word a due pagine:

Primo documentoOgni documento successivo
Protezione in tempo reale di Defender attivacirca 70 s0,3–7,5 s, a seconda del formato
Protezione in tempo reale di Defender disattivata12–15 s0,3–7,5 s, a seconda del formato

Pagalo una volta, prima che lo facciano i tuoi utenti:

  • Mantieni il processo worker attivo: imposta Start Mode del pool di applicazioni su AlwaysRunning, e aumenta o disabilita il suo idle time-out, così una notte tranquilla non scarica i motori.
  • Riscaldalo all'avvio: abilita Application Initialization di IIS (preloadEnabled="true" sul sito) e punta il suo initializationPage a una tua pagina che apre un piccolo documento. Il primo vero utente troverà così i motori già caricati.
  • Concedi tempo alla prima richiesta: un controllo di salute del load balancer o un proxy upstream con timeout breve può rinunciare a un avvio a freddo che altrimenti sarebbe riuscito.

Decidere se modificare le impostazioni dell'antivirus su un server è una decisione del tuo team di sicurezza; il riscaldamento sopra funziona senza di esso.

Il pool di applicazioni

Su un singolo server, le sessioni dei documenti e le pagine nella cache vivono nel processo worker. Ogni riciclo del pool di applicazioni — quello programmato, una modifica a Web.config, o l'idle time-out del pool (20 minuti per impostazione predefinita in IIS) — li elimina tutti, e i visualizzatori aperti mostrano quindi Document session not found. Please re-open document.

  • Allinea l'idle time-out e il programma di riciclo del pool con la durata effettiva della lettura dei tuoi utenti, o preparati a riaprire i documenti dopo un riciclo.
  • Esegui il pool come processo a 64 bit (lascia Enable 32-Bit Applications disattivato). I documenti grandi necessitano dello spazio di indirizzamento che un processo worker a 32 bit non possiede.
  • Una web farm mantiene le sessioni in un archivio condiviso, così un riciclo su un nodo non le perde — vedi Sessioni e Sicurezza.

Una checklist di ottimizzazione

  1. Imposta il valore più basso di ImageResolution accettato dalla tua UX.
  2. Mantieni CachePages attivo per la visualizzazione interattiva; disattivalo per scenari a passata singola o ad alta concorrenza.
  3. Chiudi le sessioni esplicitamente; riduci TimeOut dove l'uso è a scatti.
  4. Usa LargeDoc + AutoLoad = false predefinito sul client per documenti grandi.
  5. Usa DefaultRender = false solo quando hai bisogno di una proiezione PDF con testo.

Questa pagina è stata utile?