Discussion :

[nighma]

Bonjour,

Voilà j'ai un petit soucis et j'aimerais voir avec vous comment on peut aborder le problème. Voici la situation :

J'ai une grosse application en php qui permet au utilisateur de faire des mailings (envois de mails en masse). Certains ont des envois allant jusqu'à 40000 destinataires et la chose importante est que chaque mail est personnalisé (le contenu varie d'une personne à l'autre).

J'ai donc un script qui prépare le contenu d'un mail et l'envoie et il fonctionne bien.
J'aimerais maintenant trouver une solution afin d'automatiser l'envoi de tous les mails et cela n'importe quand dans la journée. En fait, dès qu'un mailing est prêt, je dois l'envoyer. J'ai pensé au CRON linux mais je me vois mal envoyer un mail toute les minutes, ça prendrait des mois.

Comment géreriez-vous le problème vous ?

[sabotage]

Si tu gères ton envoi avec une base de données, tu n'as qu'a marquer les mails envoyés ; et donc envoyer par lot de X ceux qui n'ont pas encore été envoyés.

[nighma]

C'est en effet à cela que j'ai réfléchi mais mon problème se situe plus au niveau de la gestion du lancement du script. Il faudrait une sorte de CRON mais qui tourne en boucle tout le temps sans prendre trop de ressources lorsqu'il n'y a pas de mailing à envoyer. J'ai fait le script qui fait un test rapide et qui fait un sleep(60) lorsqu'il n'y a pas de mail.

J'ai essayé de mettre un script Perl qui s'exécute en boucle mais je n'aime pas trop cette solution.

En avez-vous d'autres ?

[sabotage]

Il faudrait une sorte de CRON

Pourquoi pas un vrai CRON ?

[BornBanane]

Le CRON est la meilleur solution pour cela.
Les mails à envoyer, tu peux les stocker dans une base, lorsque ton script passe tu déplaces les mails envoyés dans une autre tables, ou tu changes une valeurs d'une colonne.
Tu n'as plus qu'a exécuter ton script toutes les X minutes celui-ci prenant Y mails dans la tables pour les envoyer.

Pour X et Y faut voir ce qui est le plus rentable.
Par exemple si ton script arrive a envoyer 50 mails à la minutes alors il faudra exécuter ton script toutes les minutes et celui-ci devrait envoyer au plus 50 mails à chaque fois.
Si tu utilises un X plus grand tu pourrais avoir des soucis de double envoies.

Pour éviter cela tu peux concevoir un système de "lock". En gros quand ton script démarrer tu crées un fichier texte. Et quand il se stop tu effaces ce fichier.
Il faut ensuite ajouter, avant la création du fichier, un teste portant sur l'existence de ce fichier. S'il existe alors tu ne fais rien du tout.

[nighma]

Depuis ce matin, j'y réfléchi et je suis arrivé plus ou moins à la même conclusion avec une colonne dans la table des mails qui servirait finalement de lock (un timestamp par exemple).

Il faut maintenant voir quel est le meilleur rendement concernant les X mails par minutes. Le serveur qui traite et envoie les messages est parfois soliciter par d'autres jobs, les performances ne sont donc pas linéaire.

Je dois voir maintenant ce qu'il se passe si le job lancé à la minute x+1 ne rentre pas en conflit avec le job de la minute x. Le lock devrait éviter d'envoyer 2 fois le même message normalement.