multi-sympa c'est plus sympa ?

[Aumont - Comite Reseaux des Universites <adresse@cachée>]

Encore une matinée difficile avec une liste qui demande plusieurs heures
pour la diffusion. 

Je voudrais faire tourner plusieurs sympa en paralelle de la facon suivante ?

-1- Creer 1 spool sympa par priorité

-2- Patcher le pgm de mise en spool pour qu'il dépose les messages
    dans $priorite/msg.$unique au lieu de $priorite-$msg.$unique comme
    dans la solution actuelle.

-3- Faire tourner une instance de sympa pour chaque spool chacune utisant
    un sympa.conf mentionnant 1 spool spécifique


Le seul effet de bord indésirable que je prévois : le sympa qui sera
affecté au robot partagerait les meme infos (listes d'abonnés) que les
sympa de diffusion. Les sympa de diffusion utiliserait donc une liste
d'abonné figée au moment de leur démarrage sauf en leur demandant de relire
la liste des abonnés si la date du fichier a évoluée. Ces sympa là serait
donc succeptible de passer pas mal de temps a reconstruire des Btree
opération couteuse en CPU.

Les avantages sont faciles a imaginer. : possibilité de démarrer la diffusion
d'un message très prioritaire pendant la diffusion lente d'un message peu
prioritaire.  La limite de ce bricolage, c'est le fait de partager de
facon statique le nombre maxi de sendmail. 

Suis-je à coté de mes pompes ?

---------------------------------------------------------------------------
Serge Aumont      CRU  campus Beaulieu             Tel : 02 99 84 71 47
                  35042 Rennes Cedex               fax : 02 99 84 71 67