Performance

La performance de Chinaski est conçue autour de ce que la charge de travail est réellement ; un admin avec une poignée d'éditeurs et des builds par lots périodiques. Cette page couvre les leviers à actionner : le parallélisme de build, les index de base de données, les en-têtes de cache, et les bons réglages ordonnés par impact.

D'abord : le parallélisme de build

Les builds sont l'opération coûteuse, et leur parallélisme est configurable :

• La variable d'environnement CHINASKI_JOBS a la précédence la plus haute.
• Le réglage build_jobs (Settings) vient ensuite.
• Sinon le builder utilise votre nombre de CPU.
• Les valeurs sont bornées entre 1 et 16 ; une valeur de 1 construit séquentiellement sans forking, le mode de debug.

Architecture de build parallèle : vagues de rendu par langue plus vagues par phase (les archives construites ensemble), de sorte qu'une machine chargée à bloc exécute les builds séquentiellement par pool de workers.

En-têtes de cache pour la partie statique

Les exemples nginx et Caddy livrés bornent les durées de cache pour que les visiteurs soient servis vite en revisite et que le contenu frais ne soit pas retardé :

• HTML: revalidation à 5 minutes ; le caractère périmé du contenu est borné au cycle de publication.
• sw.js: no-cache, must-revalidate (les nouveaux service workers sont poussés immédiatement).
• Polices: cache immuable d'un an.
• Autres assets: cache d'un jour.

L'application pose ses propres en-têtes de sécurité ; les en-têtes du proxy sont une ceinture et des bretelles pour les réponses servies avant que l'application ait pu répondre.

Base de données et index

La base de données est livrée avec des index de performance couvrant les pages et posts (ordre actif/mis-à-jour, arcs publiés+langue, l'index catégorie des posts), appliqués automatiquement au démarrage de l'application, idempotents à la réexécution. SQLite tourne en mode embarqué (pas de processus serveur, pas d'identifiants) en mode WAL avec un cache de 64 MiB et un busy timeout de 5 secondes. Pour la charge attendue (une session admin active, des builds par lots périodiques), SQLite est le bon choix.

Leviers de temps de build

• La minification HTML est activée par défaut ; la désactiver (réglages) échange la taille des pages contre la vitesse de build (la minification pilotée par regex est un coût de build mesurable).
• Les builds incrémentaux sont le défaut pour les rebuilds déclenchés depuis l'admin : les pages inchangées sont réutilisées plutôt que réécrites ; un build bloqué retombe sur un build complet.
• Les minutages par phase dans chaque log de build : les phases de haut niveau et les compteurs feuilles de la boucle chaude (rendu des templates, minification HTML, requêtes post) sont rapportés séparément. Ne sommez pas les deux sections ; la sortie du vérificateur montre où le temps est réellement allé.
• L'historique des minutages est persisté en JSON par build, pour que l'analyse de tendance sur l'historique propre de votre site soit facile (le dernier : interrogez le timings_json de la ligne build_log la plus récente).

Ce que le projet mesure

Le document de benchmarking livre un protocole reproductible : une DB de fixture amorcée avec un corpus de 7 000 posts et un build chronométré (avec un drapeau posé pour les exécutions jetables). La baseline documentée actuelle (trois cœurs) : corpus de 7 008 articles construit en ~162,6 s, 9 129 fichiers, 588 Mo de sortie, avec le rendu des templates notablement pas le goulot ; les coûts dominants sont la regex de minification, les passes de validation liens/accessibilité, et l'index de recherche. Utilisez ces chiffres pour comparer votre propre baseline, non comme une promesse.

Les petites choses

• Le cache de réglages du CMS a un TTL ; les lectures de réglages répétées sont servies depuis la mémoire.
• Les webhooks sont plafonnés à 8 envois concurrents, pour qu'un build riche en webhooks n'affame pas la boucle de requêtes.
• L'élagage des tables log/audit est throttlé (une fois toutes les ~15 minutes), de sorte que les travaux de maintenance n'ont pas de pointes périodiques.
• L'historique de build de l'admin et le promotion guard exécutent leurs vérifications de correction dans le même budget de temps que le build ; un build échoué ne peut faire pendre votre deploy ; les deploys en avant vers les cibles SSH/rsync ou S3 sont immédiatement l'étape suivante.