Ajuste de Desempenho
Otimize renderização e memória
O perfil de recursos do Doconut é dominado por três coisas: render DPI, o que permanece em cache, e quanto tempo as sessões permanecem vivas. Este guia percorre as alavancas em ordem de impacto.
Resolução — a maior alavanca
ImageResolution (25–300 DPI) controla tanto o tempo de renderização quanto o tamanho da imagem. A maioria dos formatos tem como padrão 200 DPI; imagens e PSD têm como padrão 100.
// Uma visualização da lista de documentos não precisa de qualidade de impressão
var token = await viewer.OpenDocumentAsync(path, new PdfConfig { ImageResolution = 100 });Reduzir o DPI pela metade diminui aproximadamente em um quarto a contagem de pixels por página — renderizações mais rápidas, transferências menores, menos memória de cache. Reserve 250–300 DPI para casos de uso com muito zoom (CAD, desenhos de engenharia).
Para PDFs com imagens incorporadas em grande quantidade, PdfConfig adiciona ajustes mais finos: CompressImages + CompressQuality, ResizeImages + ResizeResolution, e CompressFast. Para imagens simples, ImageConfig.MaxImagePixelSize (padrão 3000 px) limita o tamanho de saída.
Cache de página — memória vs. re-renderização
BaseConfig.CachePages (padrão true) mantém cada página renderizada na memória durante a vida da sessão. Esse é o padrão correto para visualização interativa — os usuários rolam para frente e para trás. Desative‑o quando:
- os documentos são enormes e visualizados uma única vez, de início ao fim,
- muitas sessões simultâneas multiplicariam as páginas em cache,
- você prefere gastar CPU por visualização a manter RAM.
var token = await viewer.OpenDocumentAsync(path, new PdfConfig { CachePages = false });No cliente, ViewerConfig.CacheEnabled = true pré‑carrega uma pequena janela móvel de imagens de páginas futuras na memória do navegador. É um cache de pré‑busca por visualização, não um localStorage persistente.
Sessões — a memória que você não vê
Cada sessão aberta mantém o modelo de documento analisado mais (com CachePages) suas páginas renderizadas, até que o TimeOut deslizante (padrão 60 minutos) expire desde a última requisição. Dois hábitos mantêm isso sob controle:
- Feche o que você terminou.
viewer.CloseDocument(token)libera o motor imediatamente em vez de aguardar a janela ociosa. - Ajuste o tempo limite adequadamente. Uma pré‑visualização que os usuários olham por dois minutos não precisa de uma sessão de uma hora:
var token = await viewer.OpenDocumentAsync(path, new DocOptions { TimeOut = 10 });Lembre‑se da compensação: após a expiração o widget exibe Document session not found. Please re-open document. — escolha um tempo limite que corresponda às sessões reais de leitura.
Alternativas específicas por formato
- Excel:
MemoryOptimizationPreferenceestá ativado por padrão e reduz a pegada de memória ao renderizar pastas de trabalho muito grandes — deixe‑o ativado, ou defina‑o comofalsese quiser trocar memória por um pequeno ganho de velocidade;SheetNames/PrintArearestringem a renderização ao que importa. - O modo de redirecionamento tem um custo inicial:
DefaultRender = falseconverte o documento inteiro para PDF no momento da abertura. Isso permite busca nativa baseada em texto, mas em um documento de 500 páginas a chamada de abertura carrega essa conversão — não o habilite reflexivamente. - Word/PowerPoint em um servidor sem as fontes dos documentos: um Windows Server sem Office tem muito menos fontes que uma máquina de desenvolvimento. Fontes ausentes causam sondagem lenta de fallback e métricas incorretas; instale as fontes, ou aponte
FontFolderspara uma pasta que as contenha.
Estratégias do lado do cliente
LargeDoc = true— estratégia de carregamento preguiçoso para documentos muito grandes; as páginas carregam à medida que o usuário se aproxima delas.AutoLoad = false(padrão) — não renderize até que você realmente chameView(token).ShowThumbs = false— ignore a geração/solicitações de miniaturas para pré‑visualizações de página única ou incorporadas.- Habilitar
FixedZoomevita alterações de zoom livre; ao mapear umViewerConfigC#, ajusteFixedZoomPercentMobile(padrão C# 75) para telas pequenas.
Inicialize uma vez, não por requisição
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance) pertence a Application_Start, ao lado de DoconutHost.Initialize — registrar codificações por requisição é trabalho desperdiçado; esquecê‑lo completamente quebra documentos legados de página de código.
O primeiro documento após uma inicialização
Doconut carrega seus motores de documento na primeira vez que um documento é aberto em uma aplicação — após o pool iniciar, após cada reciclagem, e em cada novo domínio de aplicação. Essa primeira abertura é mais lenta que as subsequentes, e antivírus em tempo real pode torná‑la muito mais lenta: os motores são carregados da memória, e o Microsoft Defender escaneia esse código ao carregá‑lo. Uma exclusão de pasta não ajuda, pois nenhum arquivo está envolvido.
Medido em uma máquina Windows Server 2022 de 4 núcleos, ao abrir um documento Word de duas páginas:
| Primeiro documento | Cada documento subsequente | |
|---|---|---|
| Defender proteção em tempo real ativada | cerca de 70 s | 0.3–7.5 s, dependendo do formato |
| Defender proteção em tempo real desativada | 12–15 s | 0.3–7.5 s, dependendo do formato |
Pague isso uma vez, antes que seus usuários o façam:
- Mantenha o processo de trabalho ativo: defina o Start Mode do pool de aplicativos como
AlwaysRunning, e aumente ou desative seu idle time-out, para que uma noite tranquila não descarregue os motores. - Aqueça‑o na inicialização: habilite a Application Initialization do IIS (
preloadEnabled="true"no site) e aponte seuinitializationPagepara uma página sua que abra um documento pequeno. O primeiro usuário real então encontrará os motores já carregados. - Conceda tempo à primeira requisição: uma verificação de integridade do balanceador de carga ou um proxy upstream com timeout curto pode desistir de uma inicialização fria que teria sucesso.
Se deve ou não alterar as configurações de antivírus em um servidor é decisão da sua equipe de segurança; o aquecimento acima funciona sem ele.
O pool de aplicativos
Em um único servidor, as sessões de documento e as páginas em cache vivem no processo de trabalho. Cada reciclagem do pool de aplicativos — a programada, uma edição em Web.config, ou o idle time-out do pool (20 minutos por padrão no IIS) — descarta tudo, e os visualizadores abertos então exibem Document session not found. Please re-open document.
- Alinhe o idle time‑out e o cronograma de reciclagem do pool com o tempo que seus usuários realmente leem, ou esteja preparado para reabrir documentos após uma reciclagem.
- Execute o pool como um processo de 64 bits (mantenha Enable 32-Bit Applications desativado). Documentos grandes precisam do espaço de endereço que um processo de trabalho de 32 bits não possui.
- Um farm web mantém sessões em um armazenamento compartilhado, então uma reciclagem em um nó não as perde — veja Sessões & Segurança.
Uma lista de verificação de ajuste
- Defina o menor
ImageResolutionque sua UX aceita. - Mantenha
CachePagesativado para visualização interativa; desativado para cenários de passagem única ou alta concorrência. - Feche sessões explicitamente; reduza
TimeOutonde o uso é intermitente. - Use
LargeDoc+ o padrãoAutoLoad = falseno cliente para documentos grandes. - Use
DefaultRender = falsesomente quando precisar de uma projeção PDF contendo texto.
Esta página foi útil?