envoir emailing grosse base de données

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : envoir emailing grosse base de données

Re: envoir emailing grosse base de données

par AB » 20 août 2009, 17:09

Déjà cette réponse me semble byzar : J'ai déjà fait tourner un script plus de 10 secondes ( largement ) et je n'ai jamais constater max execution.
Bizarre en effet ces 10 secondes vu que par défaut le max_execution_time est de 30 secondes.
Et encore dans ces trente secondes ne sont pas comptés les accès à la bdd, appels externes, ce qui fait que le temps total peut être bien supérieur. Et puis si tu es sur un dédié normalement tu pourrais définir toi-même les directives max_execution_time et set_time_limit .

Enfin bon cela ne t'empêcherait pas d'être confronté à la limite d'envoi de mail sans être considéré comme spameur.

Vu le nombre de mail que tu as à envoyer et étant donné que, comme disait Sékiltoyai, la fonction sleep compte dans le temps total du script, la solution du cron est la plus appropriée et de loin la plus fiable.

Re: envoir emailing grosse base de données

par Sékiltoyai » 19 août 2009, 15:55

Et si à la limite je laisse en temps réel au lieu d'un cron mais que je rallonge sleep à plusieurs minutes ça peut marcher aussi ?
Le délai d'une minute c'est une idée comme une autre. Ca marcherait aussi, mais je ne pense pas qu'il soit vraiment indispensable d'envoyer de manière synchrone.
Si je dit pas de bêtise sleep ne rentre pas en compte dans le temps d'exécution d'un script ?
Ah si, il compte.
Et dans ce cas, d'une part il faut faire attention à rendre la main directement au client sans arrêter le script, si tu ne le fais pas, il faut garder ton navigateur ouvert pendant tout le temps de traitement. Et ensuite il faut être sûr que le serveur ne plantera pas pendant l'envoi, parce qu'il n'y a aucune sauvegarde dans ce cas.

Contrairement à ce que l'on pourrait croire, ce n'est pas plus simple/efficace de tout faire de manière synchrone. Pour certaines tâches, un démon indépendant, qui vit sa vie de son côté est bien plus efficace et maintenable. On peut le contrôler sans influer sur le reste de l'application, il est beaucoup plus facile à intégrer à d'autres systèmes (si tu veux envoyer des mails de masse via un autre outil que php, ou programmer le cron dans un autre langage), et surtout il est totalement inconsidéré de vouloir un comportement synchrone pour quelquechose qui nécessite un fonctionnement fondamentalement asynchrone.
Je pourrais citer beaucoup d'autres arguments, comme la répartition de charge, la fiabilité, etc…

Bref, j'aimerais bien connaître l'avantage fonctionnel que tu aurais à le faire en temps-réel.

Re: envoir emailing grosse base de données

par FuZZyLine » 19 août 2009, 15:12

en effet pas mal comme solution
J'avais déjà pensé en cas de coupure a enregistrer a chaque fois le dernier id envoyé pour pouvoir reprendre
Si l'envoi est fait pas ordre d'id, ça doit pouvoir se faire
Et si à la limite je laisse en temps réel au lieu d'un cron mais que je rallonge sleep à plusieurs minutes ça peut marcher aussi ?
Si je dit pas de bêtise sleep ne rentre pas en compte dans le temps d'exécution d'un script ?
C'est qu'une piste alors pas taper lol

1) Tu load toute ta table des emails.
2) Tu créés une table avec les champs id[PRIMARY_KEY], flag_send, addr_email, time (*)
3) Tu copies le résulat de (1) vers (2) ~10 secondes chrono ou presque

Pour la gestion de l'envoie:
Tu joues avec la table (2) et lors de chaque send (réussit) tu marques le flag de l'id concerné
avec true et enregistre le time. Ainsi de suite pour le reste... Ca permet même de faire un break
puisque tu sais qui a eu ou pas le mail (si t'as des clients en HOTMAIL) la tu risques d'avoir
quelques ennuis (leur filtre spam)...

Quand c'est fini tu reportes les résultats de la table 2 (réussites/échec) vers la table 1.
C'est le mieux à mon avis et surtout le moins lourd.

(*) l'id est biensur l'id de table 1 que j'imagine PRIMARY_KEY

@+ ;)

PS1: Désolé, un peu de mal à expliquer, je comprendrais si t'as rien "capish" ;)
PS2: pour sleep regarde http://www.manuelphp.com/php/function.t ... osleep.php
c'est peut-être plus adapté à ton besoin
PS3:sleep et consort sont pas implémentées sous Win alors assure toi d'être sous un OS qui les gère

Re: envoir emailing grosse base de données

par supercanard » 19 août 2009, 14:48

en effet pas mal comme solution

J'avais déjà pensé en cas de coupure a enregistrer a chaque fois le dernier id envoyé pour pouvoir reprendre
Si l'envoi est fait pas ordre d'id, ça doit pouvoir se faire

Et si à la limite je laisse en temps réel au lieu d'un cron mais que je rallonge sleep à plusieurs minutes ça peut marcher aussi ?

Si je dit pas de bêtise sleep ne rentre pas en compte dans le temps d'exécution d'un script ?

Re: envoir emailing grosse base de données

par Sékiltoyai » 19 août 2009, 14:22

Alors, pour ça, la solution est simple :
Une table "gens" :
  • Id : Entier autoincrémenté
  • Nom : Chaine de caractères
  • Mail : Chaine de caractères
Une table "emails" :
  • Id : Entier autoincrémenté
  • Sujet : Chaine de caractères
  • From : Chaine de caractères
  • Texte : Chaine de caractères
Une table "envois" :
  • Id_gens : Entier, clé étrangère sur gens.Id
  • Id_emails : Entier, clé étrangère sur emails.Id
A chaque emailing de masse, tu insères le mail dans ta table "emails", et tu remplis ta table "envois" de correspondances "gens" <-> "emails".

Ensuite tu laisses tourner un cron, tu peux même le faire tourner la nuit si tu veux optimiser l'utilisation de ton serveur, qui toutes les minutes (configurable) prend une cinquantaine (configurable) d'enregistrements dans la table "envois" et effectue le mailing du mail correspondant au monsieur correspondant.

Tu bypasses toutes les limites, et surtout tu évites de te faire lister en spammeur parce que si tu as le malheur d'avoir tous tes clients sur le même prestataire mail, passé le centième mail, tu es quasiment sûr d'être banni au moins pour la journée.

Re: envoir emailing grosse base de données

par supercanard » 19 août 2009, 13:32

Merci pour tes précisions
Je vais faire des essais.
Pour précisions c'est un fichier clients, clients qui ont acceptés d'être contactés ;)
Dailleur ce sera moins de 25000 puisque tous n'ont pas accepté de recevoir des informations

Re: envoir emailing grosse base de données

par FuZZyLine » 19 août 2009, 13:09

Bonjour,
Je ne sais pas si 25000 adresses est considéré une "grosse base de données" pour un envoi d'emailing, mais selon mon hébergeur je ne peut pas faire un tel envoi.
Il y a bien plus gros comme BD mais s'il s'agit d'un fichier prospects c'est beaucoup. Je veux dire
25k mail à envoyer. Ca s'assimile (de mon point de vue) à du spam. Et la limite que tu as constaté est la,
justement, afin de tenter de réduite ce type d'action ;)
Nous avons pourtant un serveur dédié, je pensais donc que nous serions beaucoup moins limités, mais sa réponse est la suivante :
Un script utilisant la fonction mail() est lui aussi soumis à la limite d'exécution de 10 secondes par script; il vous faudra relancer donc le script à plusieurs reprises, en déterminant à combien de destinataires par exécution le mail pourra être envoyé; une fois les 10 secondes passées le script se termine et l'envoi de messages est donc interrompu.
Déjà cette réponse me semble byzar : J'ai déjà fait tourner un script plus de 10 secondes ( largement ) et je n'ai jamais constater max execution.
Ensuite je me demandais si en procédant de cette manière je pourrais régler le problème ?
while(...){
if($i == x){
sleep(10);
}
// traitement
$i++
}
En téhorie oui, à toi d'essayer.

Pour en revenir à ton problème je te conseille l'emploi de phpMailler, les restrictions sont moindres
qu'avec la fonction mail et donc tu es plus libre dans tes actions...

La restriction de la fonction mail (souvent) c'est : nombre X mail / Temps X. Autrement dit si tu attends
10 secondes (comme tu le fais) après chaque envoi aucun risques de lire un message d'alerte en revanche
essai d'envoyer 101 mails ou + sans attente et tu sauras ;)

Désolé si je réponds à côté.

@+ bon code ;)

PS: Le spam c'est beurk ! (joke)

envoir emailing grosse base de données

par supercanard » 19 août 2009, 12:33

Bonjour,

Je ne sais pas si 25000 adresses est considéré une "grosse base de données" pour un envoi d'emailing, mais selon mon hébergeur je ne peut pas faire un tel envoi.
Nous avons pourtant un serveur dédié, je pensais donc que nous serions beaucoup moins limités, mais sa réponse est la suivante :

Un script utilisant la fonction mail() est lui aussi soumis à la limite d'exécution de 10 secondes par script; il vous faudra relancer donc le script à plusieurs reprises, en déterminant à combien de destinataires par exécution le mail pourra être envoyé; une fois les 10 secondes passées le script se termine et l'envoi de messages est donc interrompu.

Déjà cette réponse me semble byzar : J'ai déjà fait tourner un script plus de 10 secondes ( largement ) et je n'ai jamais constater max execution.

Ensuite je me demandais si en procédant de cette manière je pourrais régler le problème ?
while(...){
if($i == x){
sleep(10);
}
// traitement
$i++
}