Hypnotoad : le modèle de serveur

Le CMS tourne comme un démon préforkant sous hypnotoad : un processus master plus des processus workers qui gèrent chacun des requêtes. Deux workers est le défaut des réglages (CHINASKI_WORKERS, variable d'env par instance), dimensionné en sécurité sur une machine de 1 Go ; passer à 4 est l'étape documentée pour un hôte de 2 Go ou plus avec des éditeurs concurrents.

Ce que le modèle implique pour vous en tant qu'opérateur :

• L'application est une adresse, plusieurs workers. Elle écoute une fois (depuis CHINASKI_LISTEN, défaut 127.0.0.1:8080 ou la variable d'env LISTEN_URL en mode démon), et les workers partagent ce listener.
• L'isolation est par processus. Un handler gourmand en mémoire est contenu ; l'enveloppe systemd (plafonnée à 1 Gio) empêche un processus en emballement d'affamer la machine.
• Le scheduler et les builds sont séparés. Les tâches programmées en interne et les longs builds émettent vers la même application ; le comportement des sous-processus de build est couvert sur la référence build.pl.

Comme le nombre de workers est une configuration par instance, le même fichier de réglages supporte plusieurs instances côte à côte (le motif d'unité chinaski@N ne change que les noms, le répertoire de travail, et l'environnement).