On en avait discuté il y a quelques temps ....
Begin forwarded message:
Date: Tue, 19 Aug 2003 09:59:01 +0200
From: "Nicolas STRANSKY [Nico]" <Nico@???>
Newsgroups: crans.informatique
Subject: Le serveur IMAP idéal ?
J'utilise Dovecot[1] depuis près d'un mois. Si comme moi vous avez
cherché longtemps la solution idéale pour lire votre mail en IMAP, ce
serveur peu connu éveillera peut-être votre intérêt. En fait il combine
de très nombreux avantages sans pour autant souffrir des inconvénients
habituels. Je m'explique (mais je ne reviendrai pas sur les innombrables
avantages de la lecture de mails à travers IMAP, plutôt qu'en local ou
en POP :) Ça pourrait faire l'objet d'un autre thread...)
Jusqu'à il y à peu, j'utilisais UW-imapd[2], qui présentait l'avantage
d'être ouvert et d'utiliser le format mbox, qui a ma préférence.
Seulement les performances devenaient réellement un problème lorsqu'il
s'agissait d'ouvrir des boîtes IMAP de plus de 10.000 messages, pour la
bonne et simple raison qu'en l'absence d'indexation non volatile, le
serveur doit se retaper le parsing du folder IMAP à chaque nouvelle
ouverture, ce qui est fort coûteux à la fois en termes de temps de
calcul et d'I/O. UW-imap gérait par contre très bien le SSL de manière
native et était d'une simplicité d'utilisation évangélique. Pour de
petites boîtes mails, il est idéal. Et puis aussi il s'entend très bien
avec IMP. Dans la série des serveur IMAP mbox, y'a aussi Qpopper sur
lequel je ne m'étendrai pas.
Une réponse souvent apportée aux problèmes de performances, est
l'utilisation du format maildir : les mails sont stockés dans un
répertoire, au sens initial du terme, un fichier par mail, et la lecture
d'un mail ne nécessite donc pas le parsing d'un fichier gigantesque en
entier, mais seulement du petit fichier correspondant au mail. Plusieurs
avantages :
- pas besoin de locking d'accès au fichier (en mbx, si le MTA veut
délivrer un mail pendant que le client veut en supprimer un autre, faut
bien s'entendre pour pas foutre le boxon)
- dégradation des perfs beaucoup moins sensible à la _taille_ des mails
(si on veut supprimer un mail parmi 101 mails de 300ko, il faut réécrire
tout le fichier mbox, soit 30Mo, ce qui prend du temps, alors qu'en
maildir il n'y a qu'un fichier à effacer, ce qui est quasi immédiat).
Inconvénient :
- le maildir trouve ses limites lorsqu'il s'agit de très grosses boîtes
contenant de petits mails, ou pour d'autres opérations spécifiques. En
fait le gain de perfs dans une utilisation courante n'est pas si
extraordinaire que ça, le maildir n'est donc pas la panacée universelle
[3]
Les deux serveurs principaux reposant sur le maildir sont Courrier et
Cyrus :
Courrier [4] c'est un peu luzinagaz®, ça fait bien plus que servir de
l'IMAP (c'est un MTA à part entière avec des fonctions IMAP).
Cyrus [5] sert en IMAP, repose sur du maildir, et... effectue une
indexation, ce qui améliore considérablement les perfs. Mais c'est un
projet assez fermé et considérablement critiqué pour cela. Par ailleurs
il faut un agent de livraison spécial, donc exit procmail, faut utiliser
cyrus, c'est la merde (Enfin on peut quand même utiliser procmail pour
le tri).
L'INDEXATION.
En fait, le secret de la rapidité repose dans la maintenance d'un index
séparé contenant les infos sur le folder IMAP. Cet index, de bien plus
petite taille que la boîte mail, permet au serveur de ne pas avoir à
tout relire pour disposer des infos et les servir au client. Du coup on
change complètement d'échelle en ce qui concerne les temps d'ouverture
et de classement de la boîte mail, que ce soit en mbox ou en maildir.
Mais ce qui manquait jusqu'à présent, c'était un serveur IMAP qui gère à
la fois le mbox, le maildir, l'indexation et le SSL, vide qui est comblé
par Dovecot :
"Dovecot should be pretty fast. [...] I believe it already beats most
other IMAP servers in overall performance. This is mostly because of
index files that Dovecot maintains; instead of having to scan through
all the data in mailbox, Dovecot can get most of the wanted information
from index with little effort. Dovecot's indexes can scale to huge
amount of messages per mailbox with hardly any noticeable slowdown. I've
tested only up to 367000 mails, but millions of messages should be no
problem."
En quoi consistent les index en pratique ? En un dossier .imap
systématiquement présent à côté de chaque boîte mail. Les perfs sont à
ce prix et franchement ça vaut le coup. Au moins, si un index est
flingué pour une raison X ou Y, on peut l'effacer sans crainte, il sera
recréé from scratch par le serveur. Et de toutes façons, Dovecot sait
gérer ce cas de figure : si l'index est endommagé ou désynchronisé, il
le détecte et le recrée ou le met à jour tout seul, donc en fait c'est
transparent pour l'utilisateur. Alors que la corruption de l'index est
problématique avec d'autres serveurs.
Par ailleurs Dovecot est un projet très ouvert et dont il est dit qu'il
repose essentiellement sur la sécurité... En fait le truc qui me bluffe
à l'usage c'est sa rapidité (fini les archivages obligés quand une boîte
dépasse 15000 mails), et les nombreuses possibilités de configuration
(si on veut le INBOX dans ~/mbox ou /var/spool/mail/toto, c'est pas un
problème ; si on veut mettre les locks dans un emplacement différent,
c'est également possible). La lecture de ce document [6] est également
intéressante. En fait, l'essayer c'est l'adopter, j'ai déjà converti
trois personnes :)
Un dernier truc, l'auteur du soft a vraiment une bonne vision des choses
: "Any kind of crash is considered as bug and will be fixed - even if it
happens only by deliberately poking the index files." Ça change de
certains autres qui envoient bouler tous ceux qui osent mettre en doute
la stabilité de leur bébé.
[1] http://dovecot.procontrol.fi/
http://packages.debian.org/testing/mail/dovecot.html
http://src.braincells.com/debian/woody/dovecot/
[2]
http://www.washington.edu/imap/
[3]
http://www.courier-mta.org/mbox-vs-maildir/
,--
|The final conclusion is that -- except in some specific instances --
|using maildirs will be just as fast -- and in sometimes much faster --
|than mbox files, while placing less of a load on the rest of the mail
|system. The claims in the UW-IMAP server's documentation regarding
|maildir performance can be supported only in certain, specific, very
|narrowly-defined conditions. There is no simple answer on which mail
|storage format is better. A lot depends on many variables that vary
|widely in different situations. Besides the raw benchmarks shown above,
|other factors include the mail server software being used, what kind of
|storage is being used, and the available network bandwidth. The final
|answer depends on all of the above.
`--
[4]
http://www.courier-mta.org/intro.html
[5]
http://asg.web.cmu.edu/cyrus/cyrus-overview-TOC.html
[6]
http://dovecot.procontrol.fi/doc/configuration.txt
--
Nico
La violence est le dernier refuge de l'incompétence.
Issac Asimov (Foundation)
--
Jérôme KIEFFER
Sur un déchet d'ordinateur.
