Mise à l'échelle du traitement de documents avec .NET Core
À mesure que votre application passe d'un projet pilote à une plateforme d'entreprise, les exigences sur votre infrastructure changent radicalement. Le traitement de documents — visualisation, conversion et OCR — est intensif en calcul. Une solution qui fonctionne parfaitement pour 10 utilisateurs peut s'arrêter net lorsqu'elle doit gérer 10 000 utilisateurs simultanés.
Dans le monde des systèmes à forte charge, la scalabilité est reine. Les développeurs ont besoin d'une architecture qui gère les pics de trafic avec souplesse, optimise les ressources et maintient les coûts prévisibles. C’est là que la combinaison du profil de performance amélioré de .NET Core et de l’architecture évolutive de Doconut brille. Dans cet article, nous explorerons des stratégies pour faire évoluer les pipelines de traitement de documents en utilisant .NET Core et Doconut efficacement.
Les caractéristiques de performance du traitement de documents
Pour évoluer efficacement, nous devons d'abord comprendre la charge de travail. Le traitement de documents est particulier car il est souvent limité simultanément par les trois principales contraintes de ressources :
- CPU Bound : Le rendu d'un PDF vectoriel complexe ou la conversion d'un dessin CAO nécessitent des calculs mathématiques importants.
- Memory Bound : Charger une carte haute résolution de 500 Mo en mémoire pour la traiter nécessite un gros tas, ce qui met sous pression le ramasse-miettes (GC).
- I/O Bound : Lire de gros fichiers source depuis le disque/cloud et écrire des tuiles en cache implique des opérations d'entrée/sortie importantes.
Faire évoluer cela nécessite une approche multi‑facettes, tirant parti des points forts du runtime moderne de .NET Core.
Stratégie 1 : la puissance de l'E/S asynchrone (Async/Await)
Les applications .NET héritées souffraient souvent de famine du pool de threads. Si une requête web bloquait un thread en attendant le chargement d’un fichier depuis le disque, le serveur manquait de threads pour gérer de nouvelles requêtes, provoquant des erreurs 503 même si le CPU n’était pas occupé.
Doconut est entièrement optimisé pour le modèle Async/Await disponible dans .NET Core. Chaque opération d’E/S — lecture du fichier source, récupération d’une licence, écriture dans le cache — doit être asynchrone.
En veillant à ce que votre contrôleur de visualisation utilise des méthodes async jusqu’au bout, une seule instance de serveur peut gérer des milliers de connexions ouvertes simultanément, en attendant efficacement la fin des E/S sans bloquer les threads.
Stratégie 2 : mise en cache distribuée
Dans une configuration monserveur, mettre en cache les pages rendues en mémoire (IMemoryCache) est rapide et facile. Mais cela échoue dans un environnement mis à l’échelle (ferme web). Si l'utilisateur A contacte le Serveur 1, la page y est mise en cache. Si sa requête suivante touche le Serveur 2, elle doit être re‑rendue, gaspillant le CPU.
Pour un traitement de documents évolutif, vous devez implémenter la mise en cache distribuée. Doconut prend en charge la création de fournisseurs de cache personnalisés. En implémentant un fournisseur de cache Redis ou SQL Server, vous vous assurez que le travail intensif de rendu d’une page n’est effectué qu’une seule fois.
- Scénario : L'utilisateur demande la page 1 du fichier "AnnualReport.pdf".
- Serveur 1 : Vérifie Redis. Non trouvé. Rend la page. Enregistre la tuile dans Redis. Retourne l’image.
- Serveur 2 (gérant un autre utilisateur) : Vérifie Redis. Trouvé ! Retourne l’image immédiatement.
Cela décharge le CPU de façon significative et garantit une expérience fluide quel que soit le nœud qui sert la requête.
Stratégie 3 : stockage en niveaux intelligent
Stocker des millions de documents nécessite une stratégie de stockage intelligente. Doconut prend en charge le streaming de fichiers directement depuis le stockage cloud (AWS S3, Azure Blob Storage) sans télécharger le fichier entier sur le disque local du serveur web au préalable.
C’est essentiel pour faire évoluer le stockage indépendamment du calcul.
- Stockage Hot (NVMe local) : Utilisé pour le cache temporaire des tuiles de documents actifs.
- Stockage Cool (S3 Standard) : Pour les documents fréquemment consultés.
- Stockage Cold (S3 Glacier) : Pour les archives.
Les API basées sur Stream de Doconut vous permettent de transmettre les données de S3 directement au moteur de rendu, maintenant une utilisation de mémoire constante quel que soit la taille du fichier sur le disque.
Conclusion
Faire évoluer un système de traitement de documents est un passage de « faire fonctionner » à « faire fonctionner universellement ». En adoptant le paradigme asynchrone de .NET Core, en adoptant une architecture microservices avec Docker, et en utilisant des stratégies intelligentes de cache et de mise en file d’attente, vous pouvez construire une solution de visualisation propulsée par Doconut qui s’étend à des millions d’utilisateurs.
Doconut n’est pas seulement une bibliothèque ; c’est un composant d’entreprise conçu pour résister aux exigences des environnements à haute concurrence. Avec la bonne architecture, votre infrastructure de documents devient une utilité invisible et illimitée plutôt qu’un goulot d’étranglement.