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.

csharp
// 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.
csharp
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:
csharp
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: MemoryOptimizationPreference está ativado por padrão e reduz a pegada de memória ao renderizar pastas de trabalho muito grandes — deixe‑o ativado, ou defina‑o como false se quiser trocar memória por um pequeno ganho de velocidade; SheetNames / PrintArea restringem a renderização ao que importa.
  • O modo de redirecionamento tem um custo inicial: DefaultRender = false converte 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 FontFolders para 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 chame View(token).
  • ShowThumbs = false — ignore a geração/solicitações de miniaturas para pré‑visualizações de página única ou incorporadas.
  • Habilitar FixedZoom evita alterações de zoom livre; ao mapear um ViewerConfig C#, ajuste FixedZoomPercentMobile (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 documentoCada documento subsequente
Defender proteção em tempo real ativadacerca de 70 s0.3–7.5 s, dependendo do formato
Defender proteção em tempo real desativada12–15 s0.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 seu initializationPage para 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

  1. Defina o menor ImageResolution que sua UX aceita.
  2. Mantenha CachePages ativado para visualização interativa; desativado para cenários de passagem única ou alta concorrência.
  3. Feche sessões explicitamente; reduza TimeOut onde o uso é intermitente.
  4. Use LargeDoc + o padrão AutoLoad = false no cliente para documentos grandes.
  5. Use DefaultRender = false somente quando precisar de uma projeção PDF contendo texto.

Esta página foi útil?