Re: [sympa-fr] Ordres de grandeur pour de larges volumes

[Serge Aumont <adresse@cachée>]

On 04/15/2010 11:26 AM, Pech Guillaume wrote:
> Bonjour,
>
> Je profites de cette conversation pour rebondir. Je procède actuellement à 
> des tests sur Sympa V6 d'envois plus ou moins importants pour trouver la 
> solution la plus adaptée à nos besoins.
>
> La configuration est la suivante : deux serveurs identiques avec Sympa 
> dessus plus 1 à X Bulks pour envoyer les emails. Le MTA sur chaque serveur 
> est Postfix 2.4, configuré à l'identique. La base de données est située sur 
> le serveur 1 (PostGreSQL).
>
> Après les tests d'envois sur une ML (de 25 à 1000 mails pour l'instant), 
> j'obtiens les résultats suivants :
> - 1,9 Message traité par seconde avec un seul serveur
> - 3,6 Messages traités par seconde avec les deux serveurs
>
> Le Delta temps utilisé pour calculer ces résultats est l'heure (à la 
> seconde près) à l'arrivé du premier email dans le Postfix (avant délivrance 
> à Sympa) et l'heure de sortie du dernier email dans Postfix (à destination 
> d'un usager).
>
> Voici mes questions :
>
> * Les résultats me paraissent faible mais j'ai du mal à me rendre compte vu 
> que c'est la première fois que j'utilise Sympa, qu'en pensez-vous ?
>   
Oui, c'est très faible. Sur notre serveur unique nous avons des perfs
bien supérieures avec du traffic réel (200 000 messages X abonnés à
l'heure) en période de pointe.
> * Lorsque je fait varier le nombre de Bulks, le résultat est assez 
> aléatoire (résultats incohérents), et ne varie pas beaucoup comparé aux 
> tests "1 serveur / 2 serveur" ... J'ai du mal à comprendre le rôle de Bulk, 
> est-ce qu'il dépose les emails dans les spools de Postfix (ce qui me semble 
> logique vu qu'on renseigne la commande "sendmail" dans sympa.conf) ? Je ne 
> comprends pas les différentes références qui sont faites à des sessions 
> SMTP ... Quelqu'un peut-il me fournir une explication détaillée (David 
> peut-être ;p) du fonctionnement de Bulk sur la partie post "prélèvement 
> dans la BDD" ?
>   
Cette vieille doc de la version 6 vous explique l'architecture
http://www.sympa.org/manual_6.0/server_architecture_for_big_services

Le bulk peut être optimisé en particulier, les 3 paramètres avg, nrcpt
et maxsmtp son très importants pour le fonctionnement de chaque bulk.pl

http://www.sympa.org/manual/conf-parameters/conf-parameters#nrcpt
http://www.sympa.org/manual/conf-parameters/conf-parameters#maxsmtp
http://www.sympa.org/manual/conf-parameters/conf-parameters#avg

Votre machine peut être totalement sous utilisée si maxsmtp (le nombre
d'appel parallèle de postfix) est trop faible ou au contraire surchargée
d'appel à postfix si nrcpt (le facteur de groupage SMTP) est trop
faible. Avec postfix, nrcpt peut être mis à des valeurs assez élevées.
Cela accélère considérablement la diffusion.

Attention toutefois, ce paramètre est inopérant quand on applique du
VERP  (variation du Return-path pour chaque destinataire ). Dans ce cas
le groupage est bloqué (un appel postfix par destinataire). Sympa fait
du VERP pour x% des abonnés à chaque mail dans une liste en faisant
varier les abonnés concernés. Ce pourcentage de VERP est controlé par un
paramètre de liste.  Autre cas ou on ne fait pas de groupage :
l'activation de la fonction de  parsing des mails pour instancier des
variables dans le corps des messages (version 6.1).

Serge Aumont

> * Avez-vous des remarques sur les choses qui pourraient expliquer mes 
> résultats incohérents ?
>
> Ces questions sont assez ouvertes, c'est pourquoi il me parait intéressant 
> de poster cette question sur la ML. N'hésitez pas à faire vos remarques.
>
> Bonne journée.
>
> Guillaume PECH
> Atos Worldline
>
>
> -----Message d'origine-----
> De : adresse@cachée [mailto:adresse@cachée] De la part de 
> Marc DEXET
> Envoyé : vendredi 2 avril 2010 09:03
> À : David Verdin; adresse@cachée
> Objet : RE: [sympa-fr] Ordres de grandeur pour de larges volumes
>
> Bonjour
>
> Merci à tous.
> J'ai transmis ces informations aux services qui hébergent l'instance sympa. 
> Nous allons procéder à des (enfin un ou deux, pas plus) tests en grandeurs 
> nature avec des messages de simple communication sans importance.
>
> Merci beaucoup.
>
> --
> Marc DeXeT
> CNRS - DSI
> Pôle Expertises
> <http://www.dsi.cnrs.fr>
>
>
>   
>> -----Message d'origine-----
>> De : adresse@cachée [mailto:adresse@cachée] De la
>> part de David Verdin
>> Envoyé : mardi 23 mars 2010 09:48
>> À : adresse@cachée
>> Objet : Re: [sympa-fr] Ordres de grandeur pour de larges volumes
>>
>> Je confirme : c'est l'envoi effectif des messages qui prend le plus de
>> temp, et il n'est pas nécessairement prédicitble : cela dépend en
>> partie
>> de la réactivité des boîtes mail en face.
>>
>> Notez cependant que, pour cette étape, tout le travail est fait par un
>> démon, bulk.pl qui peut exister en autant d'exemplaires que vous le
>> voulez. Plus il y a d'exemplaires, plus on ouvre de sessions SMTP
>> simultanées (jusqu'à la limite définie dans la config).
>>
>> Notez que, comme ce démon pioche toutes se données dans la base de
>> données, il peut tourner sur d'autres serveurs que le serveur de listes
>> (le serveur de messagerie, par exemple). voir, pour plus de détails, la
>> page concernant les infrastructures pour les envois massifs :
>> https://www.sympa.org/manual_6.0/server_architecture_for_big_services
>>
>> Cordialement,
>>
>> David Verdin
>>
>> Le 22/03/2010 17:33, Dominique LALOT a écrit :
>>     
>>> Bonjour,
>>>
>>> On a quelques milliers de listes étudiantes. La liste globale
>>>       
>> comprend
>>     
>>> 22000 étudiants. On n'y poste pas toutes les cinq minutes, mais
>>> globalement je n'en entend pas parler (ce qui est bon signe). Le
>>> backend est LDAP, mais en fait sympa marche avec sa base et ne fait
>>> que de l'import LDAP.
>>> Pour le temps de délivrance, j'avoue ne pas avoir regardé, mais il
>>> faut moins de 2 minutes à sympa. Ensuite c'est au mailer de
>>> distribuer, et là c'est forcément plus long et difficile à dire.
>>>
>>> A+
>>>
>>> Dom
>>>
>>> ----- Message de adresse@cachée ---------
>>>     Date : Mon, 22 Mar 2010 16:06:24 +0100
>>>      De : adresse@cachée
>>>  Objet : [sympa-fr] Ordres de grandeur pour de larges volumes
>>>       À : adresse@cachée
>>>
>>>
>>>       
>>>> Bonjour
>>>>
>>>> Dans le cadre d'un projet de mailings massifs et récurrent au sein
>>>>         
>> de
>>     
>>>> mon
>>>> établissement, il a été convenu d'utiliser les services sympa
>>>> hébergés au
>>>> sein d'un service l'exploitant de longue date. Il y a toute fois une
>>>> incertitude sur les ordres de grandeur auxquelles on peut s'attendre
>>>> pour de
>>>> larges volumes, et je me permets de vous les soumettre après une
>>>> recherche
>>>> relativement approfondie mais (trop) courte dans les archives et le
>>>> manuel,
>>>> merci de ne pas me RTFMiser trop vite :)
>>>>
>>>> Je sais bien que cela dépend de plusieurs paramètres (installation,
>>>> configuration) mais dans le cas où 50.000 abonnés sont décrits en
>>>> base (donc
>>>> pas de LDAP), à quel ordre de grandeur de temps dois-je m'attendre
>>>>         
>> pour
>>     
>>>> l'envoi d'un message et son arrivé chez les MTA des destinataires ?
>>>>         
>> Une
>>     
>>>> heure, une demi-heure, une journée ?
>>>>
>>>> Des optimisations particulières sont-elles à envisager ou une
>>>> configuration
>>>> relativement standard de Sympa est apte à avaler ce volume, modulo
>>>>         
>> la
>>     
>>>> configuration du serveur SMTP.
>>>>
>>>> Avez vous une idée des grosses volumétries généralement prise en
>>>> charge par
>>>> Sympa [ ça c'est pour rassurer les donneurs d'ordre et me rassurer
>>>> moi :) en
>>>> train de les rassurer ] ?
>>>>
>>>> Merci beaucoup de vos réponses
>>>>
>>>> Marc DeXeT
>>>> - en vous remerciant de bien vouloir excuser le côté un poil
>>>>         
>> cavalier
>>     
>>>> de la
>>>> demande -
>>>>
>>>>
>>>>         
>>>
>>> ----- Fin du message de adresse@cachée -----
>>>
>>>
>>>
>>>       
>> --
>> David Verdin
>> Comité réseau des universités
>>     
>
>
>
>
> Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
> exclusif de ses destinataires. Il peut également être protégé par le secret 
> professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne 
> pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin 
> ne pourra être recherchée quant au contenu de ce message. Bien que les 
> meilleurs efforts soient faits pour maintenir cette transmission exempte de 
> tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa 
> responsabilité ne saurait être recherchée pour tout dommage résultant d'un 
> virus transmis.
>
> This e-mail and the documents attached are confidential and intended solely 
> for the addressee; it may also be privileged. If you receive this e-mail in 
> error, please notify the sender immediately and destroy it. As its 
> integrity cannot be secured on the Internet, the Atos Origin group 
> liability cannot be triggered for the message content. Although the sender 
> endeavours to maintain a computer virus-free network, the sender does not 
> warrant that this transmission is virus-free and will not be liable for any 
> damages resulting from any virus transmitted.
>
>
>