Optimisation des performances

Le profil de ressources de Doconut est dominé par trois éléments : DPI de rendu, ce qui reste en cache, et la durée de vie des sessions. Ce guide parcourt les leviers par ordre d'impact.

Résolution — le levier le plus important

ImageResolution (25–300 DPI) détermine à la fois le temps de rendu et la taille de l'image. La plupart des formats utilisent 200 DPI par défaut ; les images et les PSD utilisent 100 par défaut.

// Un aperçu de la liste de documents n’a pas besoin d’une qualité d’impression
var token = await viewer.OpenDocumentAsync(path, new PdfConfig { ImageResolution = 100 });

Diviser le DPI par deux réduit d'environ un facteur quatre le nombre de pixels par page — rendus plus rapides, transferts plus petits, moins de mémoire cache. Réservez 250–300 DPI pour les cas d'utilisation nécessitant un fort zoom (CAO, dessins techniques).

Pour les PDF contenant de nombreuses images intégrées, PdfConfig ajoute des réglages plus fins : CompressImages + CompressQuality, ResizeImages + ResizeResolution, et CompressFast. Pour les images simples, ImageConfig.MaxImagePixelSize (par défaut 3000 px) limite la taille de sortie.

Mise en cache des pages — mémoire vs. nouveau rendu

BaseConfig.CachePages (par défaut true) conserve chaque page rendue en mémoire pendant toute la durée de la session. C'est le réglage par défaut approprié pour la visualisation interactive — les utilisateurs font défiler en avant et en arrière. Désactivez-le lorsque :

• les documents sont volumineux et consultés une seule fois, de la première à la dernière page,
• de nombreuses sessions concurrentes multiplieraient les pages en cache,
• vous préférez consommer du CPU par affichage plutôt que de retenir la RAM.

var token = await viewer.OpenDocumentAsync(path, new PdfConfig { CachePages = false });

Du côté client, ViewerConfig.CacheEnabled = true précharge une petite fenêtre mobile d'images de pages à venir dans la mémoire du navigateur. Il s'agit d'un cache de prélecture par vue, pas d'un localStorage persistant.

Sessions — la mémoire que vous ne voyez pas

Chaque session ouverte conserve le modèle de document analysé ainsi que (avec CachePages) ses pages rendues, jusqu'à ce que le TimeOut glissant (par défaut 60 minutes) expire depuis la dernière requête. Deux bonnes pratiques permettent de maîtriser cela :

• Fermez ce dont vous avez fini. viewer.CloseDocument(token) libère le moteur immédiatement au lieu d'attendre la fenêtre d'inactivité.
• Ajustez la durée du délai d'attente. Un aperçu que les utilisateurs consultent pendant deux minutes n'a pas besoin d'une session d'une heure :

var token = await viewer.OpenDocumentAsync(path, new DocOptions { TimeOut = 10 });

Gardez à l'esprit le compromis : après expiration le widget affiche Document session not found. Please re-open document. — choisissez un délai d'attente qui correspond aux vraies sessions de lecture.

Commutateurs spécifiques aux formats

• Excel : MemoryOptimizationPreference est activé par défaut et réduit l'empreinte mémoire lors du rendu de très grands classeurs — laissez‑le activé, ou réglez‑le sur false si vous êtes prêt à échanger de la mémoire contre un léger gain de vitesse ; SheetNames / PrintArea limitent le rendu à ce qui est pertinent.
• Le mode de redirection a un coût initial : DefaultRender = false convertit le document entier en PDF au moment de l'ouverture. Cela permet une recherche native basée sur le texte, mais sur un document de 500 pages l'appel d'ouverture inclut cette conversion — ne l'activez pas de façon réflexive.
• Word/PowerPoint sur un serveur dépourvu des polices des documents : un Windows Server sans Office possède beaucoup moins de polices qu'une machine de développement. L'absence de polices entraîne une recherche de secours lente et des métriques incorrectes ; installez les polices, ou pointez FontFolders vers un dossier qui les contient.

Stratégies côté client

• LargeDoc = true — stratégie de chargement différé pour les documents très volumineux ; les pages se chargent à mesure que l'utilisateur s'en approche.
• AutoLoad = false (par défaut) — ne pas rendre tant que vous n'appelez pas réellement View(token).
• ShowThumbs = false — ignorer la génération/demande de miniatures pour les aperçus d'une seule page ou intégrés.
• Activer FixedZoom évite les changements de zoom libres ; lorsque vous mappez un ViewerConfig C#, ajustez FixedZoomPercentMobile (par défaut C# 75) pour les petits écrans.

Démarrage unique, pas par requête

Encoding.RegisterProvider(CodePagesEncodingProvider.Instance) appartient à Application_Start, à côté de DoconutHost.Initialize — enregistrer les encodages par requête est du travail gaspillé ; l'oublier complètement casse les documents à pages de code héritées.

Le premier document après un démarrage

Doconut charge ses moteurs de documents la première fois qu'un document est ouvert dans une application — après le démarrage du pool, après chaque recyclage, et dans chaque nouveau domaine d'application. Cette première ouverture est plus lente que les suivantes, et l'antivirus en temps réel peut la ralentir considérablement : les moteurs sont chargés depuis la mémoire, et Microsoft Defender analyse ce code lors du chargement. Une exclusion de dossier n'aide pas, car aucun fichier n'est concerné.

Mesuré sur une machine Windows Server 2022 à 4 cœurs, ouverture d'un document Word de deux pages :

Payez-le une fois, avant que vos utilisateurs ne le fassent :

• Gardez le processus de travail actif : définissez le Start Mode du pool d'applications sur AlwaysRunning, et augmentez ou désactivez son idle time-out, afin qu'une nuit calme ne décharge pas les moteurs.
• Préchauffez-le au démarrage : activez Application Initialization d'IIS (preloadEnabled="true" sur le site) et pointez son initializationPage vers une de vos pages qui ouvre un petit document. Le premier utilisateur réel trouve alors les moteurs déjà chargés.
• Accordez du temps à la première requête : une vérification de santé du load balancer ou un proxy en amont avec un court délai d'attente peut abandonner un démarrage à froid qui aurait réussi.

Modifier les paramètres d'antivirus sur un serveur relève de la décision de votre équipe de sécurité ; le préchauffage ci‑dessus fonctionne sans cela.

Le pool d'applications

Sur un serveur unique, les sessions de documents et les pages en cache résident dans le processus de travail. Chaque recyclage du pool d'applications — programmé, une modification de Web.config, ou le idle time-out du pool (20 minutes par défaut dans IIS) — les supprime tous, et les visionneuses ouvertes affichent alors Document session not found. Please re-open document.

• Alignez le idle time-out du pool et le calendrier de recyclage avec la durée réelle de lecture de vos utilisateurs, ou soyez prêts à rouvrir les documents après un recyclage.
• Exécutez le pool en tant que processus 64 bits (laissez Enable 32-Bit Applications désactivé). Les documents volumineux nécessitent l'espace d'adressage qu'un processus de travail 32 bits ne possède pas.
• Un web farm conserve les sessions dans un stockage partagé, de sorte qu'un recyclage sur un nœud ne les perd pas — voir Sessions et Sécurité.

Liste de vérification d'optimisation

1. Définissez le plus bas ImageResolution que votre UX accepte.
2. Laissez CachePages activé pour la visualisation interactive ; désactivez‑le pour les scénarios à passage unique ou à forte concurrence.
3. Fermez les sessions explicitement ; raccourcissez TimeOut lorsque l'utilisation est ponctuelle.
4. Utilisez LargeDoc + le AutoLoad = false par défaut sur le client pour les gros documents.
5. Utilisez DefaultRender = false uniquement lorsque vous avez besoin d'une projection PDF contenant du texte.