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.
// 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.
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:
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 afalsese vuoi scambiare memoria per un piccolo guadagno di velocità;SheetNames/PrintArealimitano il rendering a ciò che è importante. - La modalità di reindirizzamento ha un costo iniziale:
DefaultRender = falseconverte 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
FontFoldersa 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 effettivamenteView(token).ShowThumbs = false— salta la generazione/richieste di miniature per anteprime a pagina singola o incorporate.- Abilitare
FixedZoomevita modifiche di zoom libere; quando mappi unViewerConfigC#, regolaFixedZoomPercentMobile(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 documento | Ogni documento successivo | |
|---|---|---|
| Protezione in tempo reale di Defender attiva | circa 70 s | 0,3–7,5 s, a seconda del formato |
| Protezione in tempo reale di Defender disattivata | 12–15 s | 0,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 suoinitializationPagea 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
- Imposta il valore più basso di
ImageResolutionaccettato dalla tua UX. - Mantieni
CachePagesattivo per la visualizzazione interattiva; disattivalo per scenari a passata singola o ad alta concorrenza. - Chiudi le sessioni esplicitamente; riduci
TimeOutdove l'uso è a scatti. - Usa
LargeDoc+AutoLoad = falsepredefinito sul client per documenti grandi. - Usa
DefaultRender = falsesolo quando hai bisogno di una proiezione PDF con testo.
Questa pagina è stata utile?