Bonjour,
J’ai un soucis de performance avec l’envoi d’email.
Mon application boucle sur l’ensemble des abonnés newsletter de mon site
et fait appel à la fonction d’envoi de mail pour chaque contact.
Trés classique et les mails sont bien expédiés.
Le problème est que le site est inaccessible en Http, durant l’envoi de
la newsletter.
Je pensais lancer le script d’envoi en utilisant BackroundDRB mais je ne
suis pas sur que le probleme soit résolu de cette manière.
Est ce que quelqu’un a déjà rencontré ce problème ? Est ce qu’il y a une
méthode alternative pour éviter le blocage du site lors de l’envoi
e-mailing ?
Merci !
Le 02/04/08, Frioffol F. [email protected] a écrit :
J’ai un soucis de performance avec l’envoi d’email.
Mon application boucle sur l’ensemble des abonnés newsletter de mon site
et fait appel à la fonction d’envoi de mail pour chaque contact.
Bonjour,
Déjà tu peux soulager ton serveur en passant d’une opération de
complexité
O(n) en 0(1) en n’envoyant qu’un seul courrier, mais avec tous les
destinataires en copie cachée: ton serveur va te remercier 
HTH
ook? ook! wrote:
Le 02/04/08, Frioffol F. [email protected] a écrit :
J’ai un soucis de performance avec l’envoi d’email.
Mon application boucle sur l’ensemble des abonnés newsletter de mon site
et fait appel à la fonction d’envoi de mail pour chaque contact.
Bonjour,
Déjà tu peux soulager ton serveur en passant d’une opération de
complexité
O(n) en 0(1) en n’envoyant qu’un seul courrier, mais avec tous les
destinataires en copie cachée: ton serveur va te remercier
HTH
Les soucis est que mes mails sont personnalisés , je récupère le
nom/prenom de l’utilisateurs et lui envoi donc un mail perso.
La copie cachée n’est donc pas une solution dans ce cas.
On 2 avr, 11:13, Frioffol F. [email protected]
wrote:
ook? ook! wrote:
Le 02/04/08, Frioffol F. [email protected] a écrit :
J’ai un soucis de performance avec l’envoi d’email.
Mon application boucle sur l’ensemble des abonnés newsletter de mon site
et fait appel à la fonction d’envoi de mail pour chaque contact.
Si ca bloque ton site, c’est que ton site tourne sur un seul et unique
process. Si c’est le cas tu es mal pour toutes les actions qui
prennent un peu de temps.
Rajouter un middleware à la backgroundrb/MoM/stromp/starling/beanstalk/
spawn/bj/<rajouter ici la nouveauté de la semaine> est une solution à
ton problème mais ca va également rajouter au minimum un process de
background.
Etant donné que:
-la newsletter c’est toi qui en controle la diffusion et non pas un
service web que tu offres à tes visiteurs.
-Qu’en plus ca n’occupera jamais plus d’un process en simultané
Partir dans la voie du middleware est la solution élégante mais la
solution pragmatique à ton cas précis c’est d’abord de rajouter un ou
plusieurs process mongrel pour rajouter de la concurrence à ton
application. Ca te rendra service pour tout le reste de ton
application.
ook? ook! wrote:
Bonjour,
Déjà tu peux soulager ton serveur en passant d’une opération de
complexité O(n) en 0(1) en n’envoyant qu’un seul courrier, mais avec
tous les destinataires en copie cachée: ton serveur va te remercier 
Sauf si tu veux automatiser la suppression des emails invalides. En
général on utilise un return-path unique pour chaque destinataire pour
détecter ces adresses… De plus le problème est reporté côté serveur
mail : au mieux il peut regrouper les destinataires du même domaine pour
gérer un seul échange par domaine, mais c’est fragile : pas mal de
serveurs refusent les mails avec trop de destinataires.
Note: je n’ai pas accès au post original (je filtre tout ce qui vient de
ruby-forum : à mon gout il y a trop de SPAM / trolls et compagnie depuis
l’interface web sur les listes ruby donc je ne lis que les posts des
personnes qui sont suffisamment motivées pour s’inscrire aux listes de
diffusion mail), donc je ne peux pas répondre précisément au problème de
perf.
Tout ce que je peux dire c’est que j’ai codé un système à base de Ruby
et Postfix qui envoit régulièrement des newsletter à des centaines de
milliers d’adresses comme ça en quelques heures, donc a moins d’une
contrainte particulière que je ne connais pas, a priori c’est faisable.
Lionel
merci Renaud pour ces précisions,
Effectivement mon site ne tourne que sur un seul process mongrel.
mais est ce que le probleme de " freeze " ne vient pas d’un nombre de
connexions smtp trop importantes ?
Comment être sur que le simple fait de lancer mon script d’envoi en
middleware va solutionner le problème ?
Pour info l’envoi est de 5000 mails, j’écris dans un fichier log a
chaque envoi ce qui me permet de voir que le taux d’envoi est de
14/secs.
Le 02/04/08, Frioffol F. [email protected] a écrit :
Comment être sur que le simple fait de lancer mon script d’envoi en
middleware va solutionner le problème ?
Comme je le réponds à chaque fois à mes clients sur des questions
similaires
: maquette 
ook? ook! wrote:
Le 02/04/08, Frioffol F. [email protected] a écrit :
Comment être sur que le simple fait de lancer mon script d’envoi en
middleware va solutionner le problème ?
Comme je le réponds à chaque fois à mes clients sur des questions
similaires
: maquette
En fait je parlais d’un point de vue technique et pas dans ma manière de
gérer mon projet
justement, ce qu’il dit c’est de tester par une maquette au lieu de
tergiversé et avoir des explications par d’autre personne. Ces autres
personnes ont surement testés pour être sûr. Pourquoi pas toi.
- Ca te permettra de tester l’utilisation d’un middleware, ce qui ne
peux pas être un mal si un jour tu en as besoin et ce jour viens vite.
- Tu sauras si ca marche réellement ou pas dans ton cas. Car, ton cas
peut-être différent du miens où j’aurais fait mon test.
Chaque solution est unique. Les design pattern aide a généraliser les
solutions par exemple. Mais parfois il est plus intéressant de ne pas
suivre le design pattern.
2008/4/2 Frioffol F. [email protected]:
similaires
: maquette
En fait je parlais d’un point de vue technique et pas dans ma manière de
gérer mon projet
–
Cyril M.
oui je comprends l’utilité de faire une maquette pour reproduire des
scenarios propres à mon environnement.
Dans le cas présent je ne sais pas comment je peux tester l’envoi
d’e-mail en masse dans la mesure ou le test va s’arrêter juste avant la
procédure d’envoi et donc l’appel smtp.
j’aimerai savoir si le bloquage du serveur vient du fait que je n’ai
qu’un process mongrel pour mon appli ou si c’est sendmail qui surcharge
le serveur.
On Apr 2, 1:18 pm, Frioffol F. [email protected]
wrote:
oui je comprends l’utilité de faire une maquette pour reproduire des
scenarios propres à mon environnement.
Dans le cas présent je ne sais pas comment je peux tester l’envoi
d’e-mail en masse dans la mesure ou le test va s’arrêter juste avant la
procédure d’envoi et donc l’appel smtp.
j’aimerai savoir si le bloquage du serveur vient du fait que je n’ai
qu’un process mongrel pour mon appli ou si c’est sendmail qui surcharge
le serveur.
Tu n’as pas compris comment fonctionnait Ruby on Rails ou ActionMailer
A ton avis comment j’ai deviné que tu ne tournais que sur un seul
process ?
Ruby On rails n’est pas thread safe et donc par nature mono thread, ce
qui signifie que tu ne peux traiter qu’une seule requete en
simultané.Si ton expédition de mail prend du temps, les autres personnes qui
arriveront sur ton site devront attendre que ce soit fini pour que ton
process traite leur demande.
La question n’est pas de savoir si ton smtp est lent ou pas, ou s’il
bloque je ne sais pas quoi ou pas, même s’il est rapide, géré 5000
mails prend du temps et un jour ca sera 10 000.
ActionMailer traite l’expédition de mail de facon synchrone (et ne
gère pas le traitement en batch), donc si tu l’utilises dans un
controlleur tu vas devoir attendre que tes 5000 mails aient été
accepté par ton smtp, ou sendmail ou whatever. Ca va donc forcement
bloqué ton process, 1 s ou 20000s, là n’est pas la question.
Donc ton appli est bloqué car ton process est occupé avec cet envoie
de mail, point barre.
Tu peux le gérer de plein de facon:
- middleware pour gérer ca en tache de fond
- plusieurs process mongrel (faut être fou pour ne tourner que sur un
seul de toute facon)
- reprogrammer ActionMailer pour que la communication avec le smtp
soit asynchrone au lieu d’être synchrone
- lancer l’expedition de mail dans un nouveau thread
- n’importe quelle action qui fait que ton action de controller ne
prenne pas 2 minutes
effectivement j’ai des choses à comprendre et c’est pour cette raison
que je poste des questions sur ce forum
ta réponse est trés précise et je pense opter pour la solution
middleware que j’utilise déjà sur un outil d’import de fichier.
la procédure sera donc la suivante :
1 : déclencher une requete ajax via l’admin sur un controller de gestion
d’email.
2 : rendre la main a l’utilisateur et afficher “envoi en cours”
3 : lancer un script externe grace à backgroundDRB pour l’envoi.
merci bcp pour ces précisions
Salut à tous,
Deux autres solutions simples :
- faire un script ruby et le faire lancer par une tâche cron en
utilisant script/runner pour pouvoir accéder à l’environement de prod
(ou de dev) et surtout avoir accès à ActiveRecord et autre API Rails.
- si plusieurs process mongrel tournent, faire lancer les mails par
une tâche cron qui appelle une action dédiée à cet envoi (par
exemple : MonApplI.com is for sale | HugeDomains)
Fab.
On 2 avr, 15:25, Frioffol F. [email protected]
Nb: ça peut aussi dans certains cas être intéressant de regarder ce
qui se fait comme services externes en la matière:
cf EMAIL NEWSLETTERS: 30+ Mailing List Services | Mashable,
http://www.aweber.com/
ou autres.
– Thibaut