Stirling-PDF est une solution robuste pour la manipulation de documents, mais sa polyvalence peut se traduire par une empreinte système importante. Lors du traitement de fichiers volumineux, il n'est pas rare d'observer des pics de latence ou une saturation de la mémoire vive. Pour garantir une exécution fluide, il est essentiel d'ajuster la configuration selon trois axes majeurs : la sélection de l'image de base, l'élagage des fonctionnalités superflues et le réglage fin des paramètres système.

Sélection stratégique de l'image Docker

Le projet Stirling-PDF propose plusieurs variantes de conteneurs. Le choix de l'image est le premier levier pour minimiser l'usage des ressources dès l'initialisation du service.

Pour un usage limité à la fusion, au découpage ou à la rotation de pages, la version ultra-lite est recommandée. Voici un exemple de configuration via docker-compose.yml pour privilégier la légèreté :

services:
  pdf-service:
    image: frooodle/s-pdf:latest-ultra-lite
    container_name: pdf_optimizer_lite
    ports:
      - "8080:8080"
    volumes:
      - ./stirling_data:/configs
    restart: unless-stopped

Élagage des modules et des points de terminaison

Même sur une version complète, il est possible de désactiver des moteurs spécifiques qui consomment de la mémoire en arrière-plan. Stirling-PDF utilise des variables d'environnement pour filtrer les fonctionnalités chargées au démarrage.

Désactivation par groupes de fonctions

Si la conversion de documents Office n'est pas requise, la désactivation du groupe LibreOffice permet de libérer une quantité significative de RAM (environ 250 Mo). Utilisez la variable GROUPS_TO_REMOVE :

environment:
  - GROUPS_TO_REMOVE=LibreOffice

Filtrage granulaire des Endpoints

Pour supprimer une fonctionnalité précise, comme la reconnaissance optique de caractères (OCR) ou la compression avancée, on utilise ENDPOINTS_TO_REMOVE. Cela empêche le chargement des bibliothèques associées :

# Exemple de suppression de l'OCR et de la conversion HTML
environment:
  - ENDPOINTS_TO_REMOVE=ocr-pdf,html-to-pdf

Ajustement des paramètres d'exécution

Au-delà de la strcuture de l'application, les réglages du runtime Docker et les variables de contrôle du système impactent directement la stabilité sous charge.

Limitation des ressources au niveau du conteneur

Il est prudent de définir des quotas pour éviter qu'un processus de conversion complexe ne monopolise l'intégralité du CPU de l'hôte. Dans un fichier Compose, on peut limiter les ressources ainsi :

deploy:
  resources:
    limits:
      cpus: '1.0'
      memory: 768M
    reservations:
      memory: 256M

Optimisation des métriques et des timeouts

La collecte de statistiques internes consomme des cycles CPU. Si vous n'utilisez pas de tableau de bord de surveillance, il est préférable de désactiver les métriques. Parallèlement, réduire le délai d'expiration des connexions inactives permet de libérer les threads plus rapidement.

environment:
  - METRICS_ENABLED=false
  - SYSTEM_CONNECTIONTIMEOUTMINUTES=3

Impact des optimisations sur les performances

L'application de ces méthodes transforme radicalement le comportement du service, particulièrement sur des environnements contraints comme les Raspberry Pi ou les VPS d'entrée de gamme.

L'activation optionnelle de modules comme Calibre (pour la conversion d'E-books) doit rester un choix conscient, car ce module ajoute à lui seul environ 150 Mo de charge mémoire supplémentaire. Vérifiez toujours que la variable INSTALL_BOOK_AND_ADVANCED_HTML_OPS n'est pas définie sur true si ces fonctions ne sont pas critiques pour votre flux de travail.