Je dois effectuer un traitement sur une table qui contient environ 9000
enregistrements et génère autant de courriers électroniques (les
destinataires sont des associations inscrites au site, le message en
question contient une information importante). Simultanément, le contenu
d'un champ de la table est modifié pour chaque enregistrement.
Si je lance mon programme comme ça, mon hébergeur va couiner très très fort
et il aura raison parce que je vais lui saturer son serveur de courrier.
Est-ce qu'il y aurait un moyen simple de « ralentir » le programme, par une
sorte de temporisation de quelques secondes entre l'envoi de 2 messages ?
C'est une bête boucle, tout ce qu'il y a de classique :
je crains que vous ne puissiez utiliser ce type de ralentissement (sleep)... parce que votre hébergeur a plus que certainement mis une durée d'exécution relativement basse... et votre script en pâtira.
Ah oui, en effet, encore un truc auquel je n'avais pas pensé.
Je vous conseille la chose suivante (avec test en amont sans envoyer les mails bien entendu) :
Vous arrivez sur le script pour la première fois ($start=0) et envoyez X mails ( 500 par exemple) : LIMIT $start,500
Tant que la liste complète n'est pas envoyer... un petit : meta name en html pour relire la page au bout de X seconde... cette fois avec $start+500 )
Du coup votre script continu d'envoyer les mails et de se « réexecuter » X fois jusqu'à ce que tous les mails soient partis.
Est-ce que cela revient au même que ce dont je parlais dans un message précédent : mettre une limite (par exemple 100) dans mon SELECT de départ, lancer l'exécution du programme dans mon navigateur, avec rechargement automatique de la page (et donc réexécution du programme) toutes les 3 ou 4 minutes ?
-- Pascale
Anthony <nospam@orange.fr.INVALID> écrivait
news:4885a565$0$882$ba4acef3@news.orange.fr:
je crains que vous ne puissiez utiliser ce type de ralentissement
(sleep)... parce que votre hébergeur a plus que certainement mis une
durée d'exécution relativement basse... et votre script en pâtira.
Ah oui, en effet, encore un truc auquel je n'avais pas pensé.
Je vous conseille la chose suivante (avec test en amont sans envoyer
les mails bien entendu) :
Vous arrivez sur le script pour la première fois ($start=0) et envoyez
X mails ( 500 par exemple) : LIMIT $start,500
Tant que la liste complète n'est pas envoyer... un petit :
meta name en html pour relire la page au bout de X seconde... cette
fois avec $start+500 )
Du coup votre script continu d'envoyer les mails et de se « réexecuter
» X fois jusqu'à ce que tous les mails soient partis.
Est-ce que cela revient au même que ce dont je parlais dans un message
précédent : mettre une limite (par exemple 100) dans mon SELECT de départ,
lancer l'exécution du programme dans mon navigateur, avec rechargement
automatique de la page (et donc réexécution du programme) toutes les 3 ou 4
minutes ?
je crains que vous ne puissiez utiliser ce type de ralentissement (sleep)... parce que votre hébergeur a plus que certainement mis une durée d'exécution relativement basse... et votre script en pâtira.
Ah oui, en effet, encore un truc auquel je n'avais pas pensé.
Je vous conseille la chose suivante (avec test en amont sans envoyer les mails bien entendu) :
Vous arrivez sur le script pour la première fois ($start=0) et envoyez X mails ( 500 par exemple) : LIMIT $start,500
Tant que la liste complète n'est pas envoyer... un petit : meta name en html pour relire la page au bout de X seconde... cette fois avec $start+500 )
Du coup votre script continu d'envoyer les mails et de se « réexecuter » X fois jusqu'à ce que tous les mails soient partis.
Est-ce que cela revient au même que ce dont je parlais dans un message précédent : mettre une limite (par exemple 100) dans mon SELECT de départ, lancer l'exécution du programme dans mon navigateur, avec rechargement automatique de la page (et donc réexécution du programme) toutes les 3 ou 4 minutes ?
-- Pascale
Olivier Miakinen
Le 22/07/2008 17:10, Anthony a écrit :
je crains que vous ne puissiez utiliser ce type de ralentissement (sleep)... parce que votre hébergeur a plus que certainement mis une durée d'exécution relativement basse... et votre script en pâtira.
Bien heureusement, il semble que non.
http://fr2.php.net/manual/fr/info.configuration.php#ini.max-execution-time <cit.> Le temps d'exécution maximum n'est pas affecté par des appels systèmes tels que sleep(). Reportez-vous à la fonction set_time_limit() pour plus de détails. </cit.>
http://fr2.php.net/manual/fr/function.set-time-limit.php <cit.> Note: La fonction set_time_limit() et la directive de configuration max_execution_time n'affectent que le temps d'exécution du script lui-même. Tout temps passé en dehors du script, comme un appel système utilisant system(), des opérations sur les flux, les requêtes sur base de données, etc. n'est pas pris en compte lors du calcul de la durée maximale d'exécution du script. </cit.>
Le 22/07/2008 17:10, Anthony a écrit :
je crains que vous ne puissiez utiliser ce type de ralentissement
(sleep)... parce que votre hébergeur a plus que certainement mis une
durée d'exécution relativement basse... et votre script en pâtira.
Bien heureusement, il semble que non.
http://fr2.php.net/manual/fr/info.configuration.php#ini.max-execution-time
<cit.>
Le temps d'exécution maximum n'est pas affecté par des appels systèmes
tels que sleep(). Reportez-vous à la fonction set_time_limit() pour
plus de détails.
</cit.>
http://fr2.php.net/manual/fr/function.set-time-limit.php
<cit.>
Note: La fonction set_time_limit() et la directive de configuration
max_execution_time n'affectent que le temps d'exécution du script
lui-même. Tout temps passé en dehors du script, comme un appel système
utilisant system(), des opérations sur les flux, les requêtes sur base
de données, etc. n'est pas pris en compte lors du calcul de la durée
maximale d'exécution du script.
</cit.>
je crains que vous ne puissiez utiliser ce type de ralentissement (sleep)... parce que votre hébergeur a plus que certainement mis une durée d'exécution relativement basse... et votre script en pâtira.
Bien heureusement, il semble que non.
http://fr2.php.net/manual/fr/info.configuration.php#ini.max-execution-time <cit.> Le temps d'exécution maximum n'est pas affecté par des appels systèmes tels que sleep(). Reportez-vous à la fonction set_time_limit() pour plus de détails. </cit.>
http://fr2.php.net/manual/fr/function.set-time-limit.php <cit.> Note: La fonction set_time_limit() et la directive de configuration max_execution_time n'affectent que le temps d'exécution du script lui-même. Tout temps passé en dehors du script, comme un appel système utilisant system(), des opérations sur les flux, les requêtes sur base de données, etc. n'est pas pris en compte lors du calcul de la durée maximale d'exécution du script. </cit.>
Bruno Desthuilliers
Pascale a écrit :
Bruno Desthuilliers écrivait news:4885cc73$0$2329$:
En bref : ce n'est pas parce que tu dois poster un mail à 9000 destinataires que tu dois envoyer 9000 mails (à moins bien sûr que le mail soit personnalisé pour chaque destinataire).
Il l'est, et particulièrement celui-ci.
Alors dans ce cas, effectivement, ni bcc ni un gestionnaire de newsletter ne pourront t'aider.
Pascale a écrit :
Bruno Desthuilliers <bdesth.quelquechose@free.quelquepart.fr> écrivait
news:4885cc73$0$2329$426a34cc@news.free.fr:
En bref : ce n'est pas parce que tu
dois poster un mail à 9000 destinataires que tu dois envoyer 9000
mails (à moins bien sûr que le mail soit personnalisé pour chaque
destinataire).
Il l'est, et particulièrement celui-ci.
Alors dans ce cas, effectivement, ni bcc ni un gestionnaire de
newsletter ne pourront t'aider.
Bruno Desthuilliers écrivait news:4885cc73$0$2329$:
En bref : ce n'est pas parce que tu dois poster un mail à 9000 destinataires que tu dois envoyer 9000 mails (à moins bien sûr que le mail soit personnalisé pour chaque destinataire).
Il l'est, et particulièrement celui-ci.
Alors dans ce cas, effectivement, ni bcc ni un gestionnaire de newsletter ne pourront t'aider.
Pascale
Bruno Desthuilliers écrivait news:48864443$0$2333$:
Alors dans ce cas, effectivement, ni bcc ni un gestionnaire de newsletter ne pourront t'aider.
Je crois que je vais utiliser la solution toute bête de faire les envois par paquets avec un LIMIT dans le SELECT initial, finalement, je me suis creusé la tête pour pas grand chose : dans la mesure où, simultanément à l'envoi, je fais une modif dans ma table qui me permet de savoir quels enregistrements ont été traités ou pas, cette solution est simple à mettre en ½uvre - elle le serait moins si je devais passer par une table intermédiaire que je viderais au fur et à mesure des envois. Comme quoi, de la discussion jaillit la lumière (-: Merci à tous !
-- Pascale
Bruno Desthuilliers <bdesth.quelquechose@free.quelquepart.fr> écrivait
news:48864443$0$2333$426a34cc@news.free.fr:
Alors dans ce cas, effectivement, ni bcc ni un gestionnaire de
newsletter ne pourront t'aider.
Je crois que je vais utiliser la solution toute bête de faire les envois
par paquets avec un LIMIT dans le SELECT initial, finalement, je me suis
creusé la tête pour pas grand chose : dans la mesure où, simultanément à
l'envoi, je fais une modif dans ma table qui me permet de savoir quels
enregistrements ont été traités ou pas, cette solution est simple à mettre
en ½uvre - elle le serait moins si je devais passer par une table intermédiaire
que je viderais au fur et à mesure des envois.
Comme quoi, de la discussion jaillit la lumière (-: Merci à tous !
Bruno Desthuilliers écrivait news:48864443$0$2333$:
Alors dans ce cas, effectivement, ni bcc ni un gestionnaire de newsletter ne pourront t'aider.
Je crois que je vais utiliser la solution toute bête de faire les envois par paquets avec un LIMIT dans le SELECT initial, finalement, je me suis creusé la tête pour pas grand chose : dans la mesure où, simultanément à l'envoi, je fais une modif dans ma table qui me permet de savoir quels enregistrements ont été traités ou pas, cette solution est simple à mettre en ½uvre - elle le serait moins si je devais passer par une table intermédiaire que je viderais au fur et à mesure des envois. Comme quoi, de la discussion jaillit la lumière (-: Merci à tous !
-- Pascale
Pascale
Olivier Miakinen <om+ écrivait news:g659f2$2ac7$:
Bien heureusement, il semble que non.[couic]
C'est bon à savoir. Même si je n'utilise pas cette fois ci la commande sleep, elle pourrait m'être utile une autre fois et maintenant je comprends mieux son fonctionnement.
C'est bon à savoir. Même si je n'utilise pas cette fois ci la commande
sleep, elle pourrait m'être utile une autre fois et maintenant je comprends
mieux son fonctionnement.
C'est bon à savoir. Même si je n'utilise pas cette fois ci la commande sleep, elle pourrait m'être utile une autre fois et maintenant je comprends mieux son fonctionnement.
-- Pascale
John GALLET
Bonjour,
Si je lance mon programme comme ça, mon hébergeur va couiner très très fort et il aura raison parce que je vais lui saturer son serveur de courrier.
Mauvais hébergeur, changer d'hébergeur. C'est bien pour ça que je loue mes propres machines pour ne jamais être em...é.
Blague à part: 1) relire le contrat sur ce point précis 2) techniquement, n'importe quel qmail ou sendmail est capable de prendre cette charge, surtout à l'émission. En revanche, ça ne présume en rien du temps qui s'écoulera pour vider la queue d'émission.
Est-ce qu'il y aurait un moyen simple de « ralentir » le programme, par une sorte de temporisation de quelques secondes entre l'envoi de 2 messages ?
Ca ne sert à rien car le serveur SMTP ne fait que mettre en file d'attente asynchrone et enverra à son propre rythme. C'est *SON* problème, pas celui du développeur. Ne pas oublier que le mail est encore plus asynchrone que le protocole http.
a++; JG
Bonjour,
Si je lance mon programme comme ça, mon hébergeur va couiner très très fort
et il aura raison parce que je vais lui saturer son serveur de courrier.
Mauvais hébergeur, changer d'hébergeur. C'est bien pour ça que je loue
mes propres machines pour ne jamais être em...é.
Blague à part:
1) relire le contrat sur ce point précis
2) techniquement, n'importe quel qmail ou sendmail est capable de
prendre cette charge, surtout à l'émission. En revanche, ça ne présume
en rien du temps qui s'écoulera pour vider la queue d'émission.
Est-ce qu'il y aurait un moyen simple de « ralentir » le programme, par une
sorte de temporisation de quelques secondes entre l'envoi de 2 messages ?
Ca ne sert à rien car le serveur SMTP ne fait que mettre en file
d'attente asynchrone et enverra à son propre rythme. C'est *SON*
problème, pas celui du développeur. Ne pas oublier que le mail est
encore plus asynchrone que le protocole http.
Si je lance mon programme comme ça, mon hébergeur va couiner très très fort et il aura raison parce que je vais lui saturer son serveur de courrier.
Mauvais hébergeur, changer d'hébergeur. C'est bien pour ça que je loue mes propres machines pour ne jamais être em...é.
Blague à part: 1) relire le contrat sur ce point précis 2) techniquement, n'importe quel qmail ou sendmail est capable de prendre cette charge, surtout à l'émission. En revanche, ça ne présume en rien du temps qui s'écoulera pour vider la queue d'émission.
Est-ce qu'il y aurait un moyen simple de « ralentir » le programme, par une sorte de temporisation de quelques secondes entre l'envoi de 2 messages ?
Ca ne sert à rien car le serveur SMTP ne fait que mettre en file d'attente asynchrone et enverra à son propre rythme. C'est *SON* problème, pas celui du développeur. Ne pas oublier que le mail est encore plus asynchrone que le protocole http.
a++; JG
Pascale
John GALLET écrivait news:488c8623$0$11974$:
Mauvais hébergeur, changer d'hébergeur. C'est bien pour ça que je loue mes propres machines pour ne jamais être em...é.
Il est pas mal, cet hébergeur. Je comprends ton point de vue, mais ni mon homme ni moi ne sommes compétents pour gérer un serveur dédié (sans parler du tarif), et le prix d'un serveur infogéré est un peu effrayant, surtout pour des sites qui ne rapportent pas un kopek.
Blague à part: 1) relire le contrat sur ce point précis 2) techniquement, n'importe quel qmail ou sendmail est capable de prendre cette charge, surtout à l'émission. En revanche, ça ne présume en rien du temps qui s'écoulera pour vider la queue d'émission.
Bof, je vais pas les embêter plus que ça, ce sont des gens assez réactifs quand on a un problème, donc je vais faire mes envois par paquets de 50 et voilà tout.
Ca ne sert à rien car le serveur SMTP ne fait que mettre en file d'attente asynchrone et enverra à son propre rythme. C'est *SON* problème, pas celui du développeur. Ne pas oublier que le mail est encore plus asynchrone que le protocole http.
C'est vrai.
-- Pascale
John GALLET <john.gallet@wanadoo.fr> écrivait
news:488c8623$0$11974$426a34cc@news.free.fr:
Mauvais hébergeur, changer d'hébergeur. C'est bien pour ça que je loue
mes propres machines pour ne jamais être em...é.
Il est pas mal, cet hébergeur. Je comprends ton point de vue, mais ni mon
homme ni moi ne sommes compétents pour gérer un serveur dédié (sans parler
du tarif), et le prix d'un serveur infogéré est un peu effrayant, surtout
pour des sites qui ne rapportent pas un kopek.
Blague à part:
1) relire le contrat sur ce point précis
2) techniquement, n'importe quel qmail ou sendmail est capable de
prendre cette charge, surtout à l'émission. En revanche, ça ne présume
en rien du temps qui s'écoulera pour vider la queue d'émission.
Bof, je vais pas les embêter plus que ça, ce sont des gens assez réactifs
quand on a un problème, donc je vais faire mes envois par paquets de 50 et
voilà tout.
Ca ne sert à rien car le serveur SMTP ne fait que mettre en file
d'attente asynchrone et enverra à son propre rythme. C'est *SON*
problème, pas celui du développeur. Ne pas oublier que le mail est
encore plus asynchrone que le protocole http.
Mauvais hébergeur, changer d'hébergeur. C'est bien pour ça que je loue mes propres machines pour ne jamais être em...é.
Il est pas mal, cet hébergeur. Je comprends ton point de vue, mais ni mon homme ni moi ne sommes compétents pour gérer un serveur dédié (sans parler du tarif), et le prix d'un serveur infogéré est un peu effrayant, surtout pour des sites qui ne rapportent pas un kopek.
Blague à part: 1) relire le contrat sur ce point précis 2) techniquement, n'importe quel qmail ou sendmail est capable de prendre cette charge, surtout à l'émission. En revanche, ça ne présume en rien du temps qui s'écoulera pour vider la queue d'émission.
Bof, je vais pas les embêter plus que ça, ce sont des gens assez réactifs quand on a un problème, donc je vais faire mes envois par paquets de 50 et voilà tout.
Ca ne sert à rien car le serveur SMTP ne fait que mettre en file d'attente asynchrone et enverra à son propre rythme. C'est *SON* problème, pas celui du développeur. Ne pas oublier que le mail est encore plus asynchrone que le protocole http.
C'est vrai.
-- Pascale
Bruno Desthuilliers
Pascale a écrit :
John GALLET écrivait news:488c8623$0$11974$:
Mauvais hébergeur, changer d'hébergeur. C'est bien pour ça que je loue mes propres machines pour ne jamais être em...é.
Il est pas mal, cet hébergeur. Je comprends ton point de vue, mais ni mon homme ni moi ne sommes compétents pour gérer un serveur dédié (sans parler du tarif),
dedibox : une trentaine d'euro par mois.
Evidemment, ça ne règle pas le problème du paramétrage et de l'administration su serveur...
Pascale a écrit :
John GALLET <john.gallet@wanadoo.fr> écrivait
news:488c8623$0$11974$426a34cc@news.free.fr:
Mauvais hébergeur, changer d'hébergeur. C'est bien pour ça que je loue
mes propres machines pour ne jamais être em...é.
Il est pas mal, cet hébergeur. Je comprends ton point de vue, mais ni mon
homme ni moi ne sommes compétents pour gérer un serveur dédié (sans parler
du tarif),
dedibox : une trentaine d'euro par mois.
Evidemment, ça ne règle pas le problème du paramétrage et de
l'administration su serveur...
Mauvais hébergeur, changer d'hébergeur. C'est bien pour ça que je loue mes propres machines pour ne jamais être em...é.
Il est pas mal, cet hébergeur. Je comprends ton point de vue, mais ni mon homme ni moi ne sommes compétents pour gérer un serveur dédié (sans parler du tarif),
dedibox : une trentaine d'euro par mois.
Evidemment, ça ne règle pas le problème du paramétrage et de l'administration su serveur...
Pascale
Bruno Desthuilliers écrivait news:488cce9a$0$1122$:
dedibox : une trentaine d'euro par mois.
Evidemment, ça ne règle pas le problème du paramétrage et de l'administration su serveur...
Oui. Il existe aussi des serveurs infogérés, mais c'est assez chérot. Il faut d'ailleurs que je regarde de plus près l'offre de Gandi, ils proposent aussi de l'hébergement.
-- Pascale
Bruno Desthuilliers <bdesth.quelquechose@free.quelquepart.fr> écrivait
news:488cce9a$0$1122$426a74cc@news.free.fr:
dedibox : une trentaine d'euro par mois.
Evidemment, ça ne règle pas le problème du paramétrage et de
l'administration su serveur...
Oui. Il existe aussi des serveurs infogérés, mais c'est assez chérot.
Il faut d'ailleurs que je regarde de plus près l'offre de Gandi, ils
proposent aussi de l'hébergement.
Bruno Desthuilliers écrivait news:488cce9a$0$1122$:
dedibox : une trentaine d'euro par mois.
Evidemment, ça ne règle pas le problème du paramétrage et de l'administration su serveur...
Oui. Il existe aussi des serveurs infogérés, mais c'est assez chérot. Il faut d'ailleurs que je regarde de plus près l'offre de Gandi, ils proposent aussi de l'hébergement.
