[Fsfe-france] Re: [sympa-authors] performances et migration

[Aumont]

Loic Dachary wrote:
> 
>         Bonjour,
> 
>         La FSF a un besoin urgent de données démontrant que sympa est
> capable de traiter d'importants volumes de mails. Il s'agit de convaincre
> des personnes qui utilisent actuellement un logiciel non libre. Mailman
> est jugé trop lent d'office.
> 

Concernant spécifiquement les performences, nous pouvons vous indiquer
des sites ayant de grosses listes (+de 100 000 abonnés) et ayant de très
bonnes perfs. Je crois qu'un site au moins à une listes de plus de 200 000
abonnés (nous connaisssons pus de 2000 sites utilisateurs de sympa). Nous même
diffusion 8 millions de messages par mois aux 150 000 abonnés de nos 400
listes.
La diffusion d'un message de 20ko à 16 000 abonnés prends 200 segondes sur
notre
serveur bi P2 550Mhz avec 512 MO de RAM. Nous avons déja enregistré des pics
de
300 000 messages diffusés en une heure (suite à un arret du serveur).

Voici quelques arguments d'architectures concernant les perfs :

Sympa utilise un SGBD en interne pour la preprésentation des listes d'abonnés.
De ce fait il n'y a pratiquement pas de limite sur la taille d'une liste, les
perfs en insertions et suppression d'abonnés sont indépendante de la taille
des listes.

Par ailleur le moteur de diffusion de Sympa inclue tout ce qu'il faut pour
tirer des bonnes perfs en optimisant l'utilisation de la bande passante
(groupage et tri par domain, contrôle des ressources consommées
sur le serveur). Le moteur SMTP peut être au choix sendmail, postfix, qmail ou
exim .
Nous utilisons sendmail parce que nous n'avons qucun soucis de perf, mais
postfix serait plus performent quoique pas simple à configurer dans ce cas. 

L'interface WWSympa est très ambitieuse sur le plan fonctionelle puisque nous
avons la prétention d'offrir à chacun un accueil personnalisé. Cette interface
offre
malgrès cela de très bonne perf car elle utilise un cgi résident (mod_fascgi)
permettant de concerver en mémoire un contexte complexe qui serait impossible
à
regénérer pour chaque "click".

Coté installation, il est possible de répartir sur plusieurs machines les
fonctions
de sympa: un serveur de SGBD, une machine de gestion des bounces, un serveur
HTTP et
le moteur de listes et un moteur SMTP lui même pouvant être répartis sur
plusieurs
machines utilisant du round robin. Actuelelment personne n'a eu besoin d'aller
si loin.

Enfin je voudrais insister sur la richesse des fonctionnalités de sympa : 
plugging antivirus, construction de listes à partir de source externe
(LDAP ou SGBD externe), authentification S/MIME et HTTPS, diffusion de
messages
cryptés S/MIME, interface web et messagerie entièrement "customisable",
multilinguisme etc.
La version beta propose une préférence d'abonnement pour le
multipart/alternative,
nous disposons sur la plateforme de dev d'une versioon incluant
l'authentification LDAP et de la notion de serveur virtuel.


Pour finir, il est bien évident que la FSF est une superbe vitrine pour un
projet comme le notre et bien entendu nous sommes disposés à vous aider à
"tuner"
votre installation de Sympa ou à nous déplacer pour vous doner une formation
ou encore
à faire rentrer dans nos developements des besoins qui vous seraient
spécifiques
(pourquoi pas l'authentification et la diffusion cryptée GPG ? )

Quels sont vos besoins de charges :
 -nombres de messages diffusés par jours
 -nombres d'abonnés
 -nombres de listes
 -...

Je reste à votre écoute.

Cordialement
Serge

-----------------------------------------------------------
Serge Aumont        Comité Réseaux des Universités
                     Campus Beaulieu 
                     35042 Rennes Cedex   +33 2 998 471 47


Ci-dessous un cours texte "sympa versus mailman".

Bien sur. Nous avons contacté address@hidden  pour proposer de faire de Sympa
un projet GNU. après quelques échanges de messages, on nous a demandé
de comparer mailman et sympa. Ci joint en fin de ce message ce que j'avais
écrit à ce sujet.

2/ Sympa versus Mailman ?

We are not Mailman competitor but free sofware diversity is important.

-Sympa internaly uses RDBMS and have no limit with mailing list size.
-Sympa includes X509 certificate management so distribution of ENCRYPTED
 messages is available (requires OpenSSL and a certificate for the list)
-Sympa web interface is customizable (HTML source is separated from the
 CGI and is parsed by Sympa). This interface is a portal to the site's
 ML service, not only to each  list. It provides search on the lists
 directory, a unique authentication for all the services, user preference, ...

Many features described in Mailman's TODO(http://www.list.org/todo.html)
are already available in Sympa :

- Use a real transactional database for all information, and allow
  various bits of information to come from different sources (a
  relational database, ZODB, LDAP, etc) 
- Support the `which' command. 
- Separate list admin role from list moderator role 
- A heirarchy of page designs and information: e.g. the most specialized
  of the following
  wins: site, virtual host, list, language, user. 
- Web pages should never mention turned-off features
- Allow the list-admin to require approvals for unsubs 
- Search engine for archives 
- Allow list owner to edit archive messages 
- optional form front-end to public interfaces as a filter to address
  harvesters. 
- Allow users to subscribe without selecting a password and have Mailman
  create a password for them.
- All web UI must be configurable so that it more easily integrates into
  an existing site's design. Probably means using a template language/system 
- Searching for members/addresses with regular expressions from both the
  command line and web interface
- Make it easier for an admin who manages multiple lists to handling
  pending requests sitting on all those lists. 
- Ability to ban specific troublesome users (from posting, subscribing,
  etc). Posts from banned users would be discarded.
- More flexible digests: index digests (subject and authors only, with
  URLs to retrieve the article) 
- Full creation, deletion, renaming, etc. of lists through the web (and
  email?), including fixing aliases file updates. 
- Confirmations should be both email and web based, and be used for both
  subscription
  and unsubscription (configurable by the list admin). 
- Add -join and -remove addresses for easy subscription, unsubscription 
- Plain text digests should conform to RFC 1153. 
- If a message has MIME parts and the header/footer is going to be
  added, the message should be transformed into a mulitpart/mixed with
  the header and footer added as text/plain parts. 
- Keep a members Real Name with their email address 
- Member profiles



> 
> --
> Loic   Dachary         http://www.dachary.org/  address@hidden
> 24 av Secretan         http://www.senga.org/      address@hidden
> 75019    Paris         Tel: 33 1 42 45 09 16        address@hidden
>         GPG Public Key: http://www.dachary.org/loic/gpg.txt

-- 
-----------------------------------------------------------
Serge Aumont        Comité Réseaux des Universités
                     Campus Beaulieu 
                     35042 Rennes Cedex   +33 2 998 471 47