Je suis confronté à un problème de gestion des envois en masse d'e-mail,
à savoir que le serveur est dans les choux aux alentours du 2500e e-mail
(pas de message d'erreur, pas de retour HTTP, page blanche et script
arrêté).
Le site est hébergé en mutualisé chez OVH.
Qu'en pensez-vous ?
Je suis confronté à un problème de gestion des envois en masse d'e-mail,
à savoir que le serveur est dans les choux aux alentours du 2500e e-mail
(pas de message d'erreur, pas de retour HTTP, page blanche et script
arrêté).
Le site est hébergé en mutualisé chez OVH.
Qu'en pensez-vous ?
Je suis confronté à un problème de gestion des envois en masse d'e-mail,
à savoir que le serveur est dans les choux aux alentours du 2500e e-mail
(pas de message d'erreur, pas de retour HTTP, page blanche et script
arrêté).
Le site est hébergé en mutualisé chez OVH.
Qu'en pensez-vous ?
Bonjour,
Je suis confronté à un problème de gestion des envois en masse d'e-mail,
à savoir que le serveur est dans les choux aux alentours du 2500e e-mail
(pas de message d'erreur, pas de retour HTTP, page blanche et script
arrêté).
J'utilise la classe PHPMailer, avec la méthode d'envoi par défaut
"mail". Les e-mails sont rédigés en HTML. Le site est hébergé en
mutualisé chez OVH.
1. Augmenter le timeout sur le serveur. Ça parait la solution simple et
idéale, vu que le serveur actuel permet de passer par "set_time_limit".
Le problème, c'est qu'il faut tester cette solution et que c'est très
gênant de balancer 10000 e-mails dans la nature sans savoir ce qu'ils
deviennent (au cas où ça ne fonctionne toujours pas). Et puis je reste
tributaire du paramétrage serveur (un safe-mode et c'est foutu).
2. Créer un fichier d'envoi, comprenant les coordonnées des
destinataires, et découper ce fichier par tranche (de 2000 contacts par
exemple). Puis lancer autant de fois le script qu'il y a de tranches.
3. Créer un fichier d'envoi unique, et gérer un point d'arrêt tous les
2000 contacts. Ça peut se faire simplement en marquant les coordonnées
servies, ou en les effaçant successivement du fichier pour traiter ceux
qui restent.
4. Faire un script qui, après avoir enregistré les coordonnées des
contacts (dans un fichier ou une table BDD), affichera une page WEB qui
va gérer les envois un par un.
Cette page appellera pour chaque contact, en AJAX récursif, un autre
script chargé d'envoyer l'e-mail et de retourner l'identifiant du
contact suivant. Cette page pourrait aussi afficher successivement les
coordonnées des contacts servis, pour suivre les envois en temps réel.
La dernière solution, un peu plus complexe à mettre en ½uvre, a
l'avantage de fonctionner à tous les coups et quelque soient les
limitations du serveur.
Elle est aussi très visuelle, car on a jamais d'informations sur ce que
fait le serveur quand on utilise les techniques habituelles.
Bonjour,
Je suis confronté à un problème de gestion des envois en masse d'e-mail,
à savoir que le serveur est dans les choux aux alentours du 2500e e-mail
(pas de message d'erreur, pas de retour HTTP, page blanche et script
arrêté).
J'utilise la classe PHPMailer, avec la méthode d'envoi par défaut
"mail". Les e-mails sont rédigés en HTML. Le site est hébergé en
mutualisé chez OVH.
1. Augmenter le timeout sur le serveur. Ça parait la solution simple et
idéale, vu que le serveur actuel permet de passer par "set_time_limit".
Le problème, c'est qu'il faut tester cette solution et que c'est très
gênant de balancer 10000 e-mails dans la nature sans savoir ce qu'ils
deviennent (au cas où ça ne fonctionne toujours pas). Et puis je reste
tributaire du paramétrage serveur (un safe-mode et c'est foutu).
2. Créer un fichier d'envoi, comprenant les coordonnées des
destinataires, et découper ce fichier par tranche (de 2000 contacts par
exemple). Puis lancer autant de fois le script qu'il y a de tranches.
3. Créer un fichier d'envoi unique, et gérer un point d'arrêt tous les
2000 contacts. Ça peut se faire simplement en marquant les coordonnées
servies, ou en les effaçant successivement du fichier pour traiter ceux
qui restent.
4. Faire un script qui, après avoir enregistré les coordonnées des
contacts (dans un fichier ou une table BDD), affichera une page WEB qui
va gérer les envois un par un.
Cette page appellera pour chaque contact, en AJAX récursif, un autre
script chargé d'envoyer l'e-mail et de retourner l'identifiant du
contact suivant. Cette page pourrait aussi afficher successivement les
coordonnées des contacts servis, pour suivre les envois en temps réel.
La dernière solution, un peu plus complexe à mettre en ½uvre, a
l'avantage de fonctionner à tous les coups et quelque soient les
limitations du serveur.
Elle est aussi très visuelle, car on a jamais d'informations sur ce que
fait le serveur quand on utilise les techniques habituelles.
Bonjour,
Je suis confronté à un problème de gestion des envois en masse d'e-mail,
à savoir que le serveur est dans les choux aux alentours du 2500e e-mail
(pas de message d'erreur, pas de retour HTTP, page blanche et script
arrêté).
J'utilise la classe PHPMailer, avec la méthode d'envoi par défaut
"mail". Les e-mails sont rédigés en HTML. Le site est hébergé en
mutualisé chez OVH.
1. Augmenter le timeout sur le serveur. Ça parait la solution simple et
idéale, vu que le serveur actuel permet de passer par "set_time_limit".
Le problème, c'est qu'il faut tester cette solution et que c'est très
gênant de balancer 10000 e-mails dans la nature sans savoir ce qu'ils
deviennent (au cas où ça ne fonctionne toujours pas). Et puis je reste
tributaire du paramétrage serveur (un safe-mode et c'est foutu).
2. Créer un fichier d'envoi, comprenant les coordonnées des
destinataires, et découper ce fichier par tranche (de 2000 contacts par
exemple). Puis lancer autant de fois le script qu'il y a de tranches.
3. Créer un fichier d'envoi unique, et gérer un point d'arrêt tous les
2000 contacts. Ça peut se faire simplement en marquant les coordonnées
servies, ou en les effaçant successivement du fichier pour traiter ceux
qui restent.
4. Faire un script qui, après avoir enregistré les coordonnées des
contacts (dans un fichier ou une table BDD), affichera une page WEB qui
va gérer les envois un par un.
Cette page appellera pour chaque contact, en AJAX récursif, un autre
script chargé d'envoyer l'e-mail et de retourner l'identifiant du
contact suivant. Cette page pourrait aussi afficher successivement les
coordonnées des contacts servis, pour suivre les envois en temps réel.
La dernière solution, un peu plus complexe à mettre en ½uvre, a
l'avantage de fonctionner à tous les coups et quelque soient les
limitations du serveur.
Elle est aussi très visuelle, car on a jamais d'informations sur ce que
fait le serveur quand on utilise les techniques habituelles.
Le problème principal, c'est que PHP n'est pas fait pour administrer une
liste de diffusion.
Je ne sais pas si l'offre est accessibles aux hébergements mutualisés
mais j'ai trouvé ça chez OVH : http://guides.ovh.com/AdministrerMailingList
J'en pense que tu devrais en parler avec ton hébergeur pour avoir
une vraie offre de liste de diffusion (avec en général gestion des
inscriptions et désinscriptions, traitement des adresses en erreur,
etc.) plutôt qu'un bricolage en PHP.
Le problème principal, c'est que PHP n'est pas fait pour administrer une
liste de diffusion.
Je ne sais pas si l'offre est accessibles aux hébergements mutualisés
mais j'ai trouvé ça chez OVH : http://guides.ovh.com/AdministrerMailingList
J'en pense que tu devrais en parler avec ton hébergeur pour avoir
une vraie offre de liste de diffusion (avec en général gestion des
inscriptions et désinscriptions, traitement des adresses en erreur,
etc.) plutôt qu'un bricolage en PHP.
Le problème principal, c'est que PHP n'est pas fait pour administrer une
liste de diffusion.
Je ne sais pas si l'offre est accessibles aux hébergements mutualisés
mais j'ai trouvé ça chez OVH : http://guides.ovh.com/AdministrerMailingList
J'en pense que tu devrais en parler avec ton hébergeur pour avoir
une vraie offre de liste de diffusion (avec en général gestion des
inscriptions et désinscriptions, traitement des adresses en erreur,
etc.) plutôt qu'un bricolage en PHP.
Bonjour,
Est-il possible, avec ta classe PHPMailer ou autre que tu pourrais y
substituer (je ne connais pas) de ne *pas* passer par un serveur HTTP,
qui est ici complètement inutile et potentiellement sources d'emmerdes
(d'ailleurs c'est ton cas).
L'idée serait de lancer ton script directement en ligne de commande, à
la main, ou de programmer par CRON une exécution régulière de ce
dernier.
Tu ne log pas la réponse du serveur de mail distant ? Comment sais-tu
alors s'ils ont bien été acceptés ? Et ceux qui ne l'auraient pas été ?
Cela dit si tu tiens absolument à passer par la chaîne navigateur >
serveur httpd > PHP, c'est à mon avis cette solution la meilleure. Mais
il faut bien sûr s'assurer de la bonne/mauvaise livraison des mails,
gérer les erreurs et stocker tout ça quelque part pour le ré-exploiter.
J'utilise une technique basique et « habituelle », toutes les infos
sur la liste, les contacts et les retours des serveurs sont dans une
base de données et j'ai un front qui me sort des informations et
statistiques de tout ça en temps réel donc je sais à peu prêt comment
les choses se passent, ainsi que mes clients.
Je suis d'accord avec Olivier pour dire que ce n'est pas forcément la
meilleure approche, bien qu'il soit possible de faire un truc propre en
PHP ce n'est sûrement pas la vocation première de ce langage.
Bonjour,
Est-il possible, avec ta classe PHPMailer ou autre que tu pourrais y
substituer (je ne connais pas) de ne *pas* passer par un serveur HTTP,
qui est ici complètement inutile et potentiellement sources d'emmerdes
(d'ailleurs c'est ton cas).
L'idée serait de lancer ton script directement en ligne de commande, à
la main, ou de programmer par CRON une exécution régulière de ce
dernier.
Tu ne log pas la réponse du serveur de mail distant ? Comment sais-tu
alors s'ils ont bien été acceptés ? Et ceux qui ne l'auraient pas été ?
Cela dit si tu tiens absolument à passer par la chaîne navigateur >
serveur httpd > PHP, c'est à mon avis cette solution la meilleure. Mais
il faut bien sûr s'assurer de la bonne/mauvaise livraison des mails,
gérer les erreurs et stocker tout ça quelque part pour le ré-exploiter.
J'utilise une technique basique et « habituelle », toutes les infos
sur la liste, les contacts et les retours des serveurs sont dans une
base de données et j'ai un front qui me sort des informations et
statistiques de tout ça en temps réel donc je sais à peu prêt comment
les choses se passent, ainsi que mes clients.
Je suis d'accord avec Olivier pour dire que ce n'est pas forcément la
meilleure approche, bien qu'il soit possible de faire un truc propre en
PHP ce n'est sûrement pas la vocation première de ce langage.
Bonjour,
Est-il possible, avec ta classe PHPMailer ou autre que tu pourrais y
substituer (je ne connais pas) de ne *pas* passer par un serveur HTTP,
qui est ici complètement inutile et potentiellement sources d'emmerdes
(d'ailleurs c'est ton cas).
L'idée serait de lancer ton script directement en ligne de commande, à
la main, ou de programmer par CRON une exécution régulière de ce
dernier.
Tu ne log pas la réponse du serveur de mail distant ? Comment sais-tu
alors s'ils ont bien été acceptés ? Et ceux qui ne l'auraient pas été ?
Cela dit si tu tiens absolument à passer par la chaîne navigateur >
serveur httpd > PHP, c'est à mon avis cette solution la meilleure. Mais
il faut bien sûr s'assurer de la bonne/mauvaise livraison des mails,
gérer les erreurs et stocker tout ça quelque part pour le ré-exploiter.
J'utilise une technique basique et « habituelle », toutes les infos
sur la liste, les contacts et les retours des serveurs sont dans une
base de données et j'ai un front qui me sort des informations et
statistiques de tout ça en temps réel donc je sais à peu prêt comment
les choses se passent, ainsi que mes clients.
Je suis d'accord avec Olivier pour dire que ce n'est pas forcément la
meilleure approche, bien qu'il soit possible de faire un truc propre en
PHP ce n'est sûrement pas la vocation première de ce langage.
En résumé, ma question est toujours : comment résoudre le problème
de capacité d'envoi d'e-mails en masse sur un serveur mutualisé,
tout en conservant l'intégration de ce service dans l'application
existante qui gère tout le reste ?
En résumé, ma question est toujours : comment résoudre le problème
de capacité d'envoi d'e-mails en masse sur un serveur mutualisé,
tout en conservant l'intégration de ce service dans l'application
existante qui gère tout le reste ?
En résumé, ma question est toujours : comment résoudre le problème
de capacité d'envoi d'e-mails en masse sur un serveur mutualisé,
tout en conservant l'intégration de ce service dans l'application
existante qui gère tout le reste ?
La question revient souvent ; elle avait longuement été débattue sur
les forums de feus phpinfo.net et phpapps.org. Avec tes contraintes,
la seule solution consiste à saucissonner ie envoyer les mails par
paquet par exemple de 100 à 200 mails et à appeler le script autant
de fois que nécessaire. Si ton hébergeur n'autorise pas le cron en
mutualisé, il existe des services en ligne qui permettent d'y
pallier (par exemple webcron).
La question revient souvent ; elle avait longuement été débattue sur
les forums de feus phpinfo.net et phpapps.org. Avec tes contraintes,
la seule solution consiste à saucissonner ie envoyer les mails par
paquet par exemple de 100 à 200 mails et à appeler le script autant
de fois que nécessaire. Si ton hébergeur n'autorise pas le cron en
mutualisé, il existe des services en ligne qui permettent d'y
pallier (par exemple webcron).
La question revient souvent ; elle avait longuement été débattue sur
les forums de feus phpinfo.net et phpapps.org. Avec tes contraintes,
la seule solution consiste à saucissonner ie envoyer les mails par
paquet par exemple de 100 à 200 mails et à appeler le script autant
de fois que nécessaire. Si ton hébergeur n'autorise pas le cron en
mutualisé, il existe des services en ligne qui permettent d'y
pallier (par exemple webcron).
J'utilise une technique basique et « habituelle », toutes les infos
sur la liste, les contacts et les retours des serveurs sont dans une
base de données et j'ai un front qui me sort des informations et
statistiques de tout ça en temps réel donc je sais à peu prêt comment
les choses se passent, ainsi que mes clients.
J'aimerais bien en savoir plus sur ta technique !
L'application est en PHP ? Comment sont déclenchés les envois d'e-mail ?
Les retours sont gérés par la même application ? etc.
Je suis d'accord avec Olivier pour dire que ce n'est pas forcément la
meilleure approche, bien qu'il soit possible de faire un truc propre en
PHP ce n'est sûrement pas la vocation première de ce langage.
Ok, mais comment faire lorsque la plateforme de gestion des contacts (et
des campagnes par e-mailing) est déjà écrite en PHP ?
Olivier suggérait l'utilisation de la gestion de listes de diffusion
chez OVH. Certes, le service existe bien, mais alors je ne disposerais
d'aucune connectivité applicative entre ce service et ma gestion de
contacts existante (ou alors je ne sais pas faire).
En résumé, ma question est toujours : comment résoudre le problème de
capacité d'envoi d'e-mails en masse sur un serveur mutualisé, tout en
conservant l'intégration de ce service dans l'application existante qui
gère tout le reste ?
J'utilise une technique basique et « habituelle », toutes les infos
sur la liste, les contacts et les retours des serveurs sont dans une
base de données et j'ai un front qui me sort des informations et
statistiques de tout ça en temps réel donc je sais à peu prêt comment
les choses se passent, ainsi que mes clients.
J'aimerais bien en savoir plus sur ta technique !
L'application est en PHP ? Comment sont déclenchés les envois d'e-mail ?
Les retours sont gérés par la même application ? etc.
Je suis d'accord avec Olivier pour dire que ce n'est pas forcément la
meilleure approche, bien qu'il soit possible de faire un truc propre en
PHP ce n'est sûrement pas la vocation première de ce langage.
Ok, mais comment faire lorsque la plateforme de gestion des contacts (et
des campagnes par e-mailing) est déjà écrite en PHP ?
Olivier suggérait l'utilisation de la gestion de listes de diffusion
chez OVH. Certes, le service existe bien, mais alors je ne disposerais
d'aucune connectivité applicative entre ce service et ma gestion de
contacts existante (ou alors je ne sais pas faire).
En résumé, ma question est toujours : comment résoudre le problème de
capacité d'envoi d'e-mails en masse sur un serveur mutualisé, tout en
conservant l'intégration de ce service dans l'application existante qui
gère tout le reste ?
J'utilise une technique basique et « habituelle », toutes les infos
sur la liste, les contacts et les retours des serveurs sont dans une
base de données et j'ai un front qui me sort des informations et
statistiques de tout ça en temps réel donc je sais à peu prêt comment
les choses se passent, ainsi que mes clients.
J'aimerais bien en savoir plus sur ta technique !
L'application est en PHP ? Comment sont déclenchés les envois d'e-mail ?
Les retours sont gérés par la même application ? etc.
Je suis d'accord avec Olivier pour dire que ce n'est pas forcément la
meilleure approche, bien qu'il soit possible de faire un truc propre en
PHP ce n'est sûrement pas la vocation première de ce langage.
Ok, mais comment faire lorsque la plateforme de gestion des contacts (et
des campagnes par e-mailing) est déjà écrite en PHP ?
Olivier suggérait l'utilisation de la gestion de listes de diffusion
chez OVH. Certes, le service existe bien, mais alors je ne disposerais
d'aucune connectivité applicative entre ce service et ma gestion de
contacts existante (ou alors je ne sais pas faire).
En résumé, ma question est toujours : comment résoudre le problème de
capacité d'envoi d'e-mails en masse sur un serveur mutualisé, tout en
conservant l'intégration de ce service dans l'application existante qui
gère tout le reste ?
La seule partie que je peux diffuser est une version du mailer :
http://pastie.org/386474
La seule partie que je peux diffuser est une version du mailer :
http://pastie.org/386474
La seule partie que je peux diffuser est une version du mailer :
http://pastie.org/386474
J'utilise la classe PHPMailer, avec la méthode d'envoi par défaut
"mail". Les e-mails sont rédigés en HTML. Le site est hébergé en
mutualisé chez OVH.
Qu'en pensez-vous ?
Cordialement,
Pascal
J'utilise la classe PHPMailer, avec la méthode d'envoi par défaut
"mail". Les e-mails sont rédigés en HTML. Le site est hébergé en
mutualisé chez OVH.
Qu'en pensez-vous ?
Cordialement,
Pascal
J'utilise la classe PHPMailer, avec la méthode d'envoi par défaut
"mail". Les e-mails sont rédigés en HTML. Le site est hébergé en
mutualisé chez OVH.
Qu'en pensez-vous ?
Cordialement,
Pascal
L'idée serait de lancer ton script directement en ligne de commande, à
la main, ou de programmer par CRON une exécution régulière de ce
dernier.
Je n'ai pas autant de libertés sur un serveur mutualisé
L'idée serait de lancer ton script directement en ligne de commande, à
la main, ou de programmer par CRON une exécution régulière de ce
dernier.
Je n'ai pas autant de libertés sur un serveur mutualisé
L'idée serait de lancer ton script directement en ligne de commande, à
la main, ou de programmer par CRON une exécution régulière de ce
dernier.
Je n'ai pas autant de libertés sur un serveur mutualisé