PHP nieuwsbrief versturen naar +/- 5000 leden gaat niet.

[bartosiej]

Hallo,

ik heb een site met ongeveer 5000 leden en daar verstuur ik ongeveer 1x p/maand een nieuwsbrief naar toe. Maar op de manier hoe ik het nu doe loopt het script vast, het script is eerst ongeveer minuutje bezig en dan krijg ik een pagina te zien van "Deze pagina kan niet gevonden worden."

Dit komt denk ik doordat het script te lang bezig is om al die emails naar al die gebruikers te sturen, dus ik heb op php.net een functie gezocht zodat dit wel kon en toen kwam ik uit op: set_time_limit();

Deze functie heb ik bovenaan staan met een waarde van 300, maar dit maakt geen verschil uit.

Het nieuwsbrief verstuur script ziet er ongeveer zo uit:

code:

<?
ob_start();
set_time_limit(300);
include('includes/config.php');

$select = mysql_query("SELECT * FROM gebruikers");
while($list = mysql_fetch_object($select))
{
    mail("$list->email", "Gratiz Webtoolz - $onderwerp", "
    Hallo $list->naam,<br>
    <br>
    $bericht
    <br><br>
    Met vriendelijke groet,<br>
    <br>
    Webmaster GratizWebtoolz.nl<br>
    <a href='$siteurl' target='_blank'>$siteurl</a><br>
    <br>
    Let op: Dit is een automatisch verstuurde email, u kunt hier niet op reageren!
    ",
    "From: GratizWebtoolz<[e-mail]>\r\nReturn-path: [e-mail]\r\nContent-type: text/html; charset=iso-8859-1");
}

ob_end_flush();
?>

Weet iemand wat ik aan mijn script om moet aanpassen zodat het script niet halverwege vastloopt?

alvast bedankt,

bartosiej

[nemesis_]

op php.net staat ook dat je 0 als waarde mee kan geven en daarmee nooit een timeout zou moeten krijgen.
en dit staat er ook: set_time_limit() has no effect when PHP is running in safe mode. There is no workaround other than turning off safe mode or changing the time limit in the php.ini.
misschien even checken?

[DataGhost]

waarom buffer je je output? je zou ook na elke verzonden mail een id kunnen echoen en daarna een flush() doen, dan zou je iig content moeten krijgen in je browser (die dan niet gaat klagen als t goed is)
als je het sjiek wilt doen kan je een span maken waarvan je met javascript de innerhtml steeds verandert (x/y gedaan (z%))

en je zou natuurlijk je bericht VOOR je while-loop in elkaar kunnen zetten ipv het elke iteratie opnieuw te construeren, scheelt aanzienlijk met zoveel records, dunkt me

[ Voor 21% gewijzigd door DataGhost op 25-04-2006 08:17 ]

[GewoonNico]

Toevallig, Ik zit met hetzelfde probleem.

FF Bookmarken ;-)

[bartosiej]

nemesis_ schreef op dinsdag 25 april 2006 @ 08:12:
op php.net staat ook dat je 0 als waarde mee kan geven en daarmee nooit een timeout zou moeten krijgen.
en dit staat er ook: set_time_limit() has no effect when PHP is running in safe mode. There is no workaround other than turning off safe mode or changing the time limit in the php.ini.
misschien even checken?

Dit kan ik wel een keer proberen, maar een timeout van 300 (=5 minuten), moet ook wel genoeg zijn toch? Zolang is het script namelijk niet bezig voordat het vastloopt.

DataGhost schreef op dinsdag 25 april 2006 @ 08:16:
waarom buffer je je output? je zou ook na elke verzonden mail een id kunnen echoen en daarna een flush() doen, dan zou je iig content moeten krijgen in je browser (die dan niet gaat klagen als t goed is)
als je het sjiek wilt doen kan je een span maken waarvan je met javascript de innerhtml steeds verandert (x/y gedaan (z%))

en je zou natuurlijk je bericht VOOR je while-loop in elkaar kunnen zetten ipv het elke iteratie opnieuw te construeren, scheelt aanzienlijk met zoveel records, dunkt me

Ik buffer de output omdat ik opdiezelfde pagina ook gebruik maak van header(); Ik kan na elk verzonden email wel het id echoen, maar of ik daar nou zoveel mee opschiet...

Het is namelijk niet zo dat ik meteen ff kan testen of het werkt, ik denk dat die 5000 leden niet zitten te wachten op allemaal test-emailtjes.

Ik kan het bericht niet voor de while-loop in elkaar zetten, omdat in het bericht allemaal dingen staan die uit de database worden gehaald voor de user waar die op dat moment mee bezig is, zoals $list->email en $list->naam.

[ Voor 23% gewijzigd door bartosiej op 25-04-2006 08:28 ]

[DataGhost]

bartosiej schreef op dinsdag 25 april 2006 @ 08:27:
[...]
Dit kan ik wel een keer proberen, maar een timeout van 300 (=5 minuten), moet ook wel genoeg zijn toch? Zolang is het script namelijk niet bezig voordat het vastloopt.


[...]
Ik buffer de output omdat ik opdiezelfde pagina ook gebruik maak van header(); Ik kan na elk verzonden email wel het id echoen, maar of ik daar nou zoveel mee opschiet...

Het is namelijk niet zo dat ik meteen ff kan testen of het werkt, ik denk dat die 5000 leden niet zitten te wachten op allemaal test-emailtjes.

Ik kan het bericht niet voor de while-loop in elkaar zetten, omdat in het bericht allemaal dingen staan die uit de database worden gehaald voor de user waar die op dat moment mee bezig is, zoals $list->email en $list->naam.

email komt niet in het bericht voor en de naam zou je weg kunnen laten (weinig tot geen toegevoegde waarde, een krant maakt ook geen persoonlijk exemplaar voor iedereen)
en wat header() je dan? een location? dat kan je namelijk gewoon oplossen met een javascript location.href. Wie weet gaat het zelfs fout bij die header (als t een location is) en kan ie de pagina niet vinden waar je heen verwijst... dat is nou ook het nut van dat ID echoen, dan zie je direct waar het fout gaat (desnoods haal je mail() weg), of ie uberhaupt iets doet, wanneer ie stopt en wellicht dat ie gewoon alle mailtjes heeft verstuurd en daarna crapt op je header.

[RedBeard]

Ik heb ooit ook iets dergelijks gebouwd. Ik weet niet meer exact hoe ik het opgelost heb maar volgens mij ook d.m.v. flush() of ob_flush() hierdoor voorkwam ik de timeout

ik zal even in mijn oude code gaan zoeken of ik het terug kan vinden.

[zeroxcool]

Of je verzendt pak 'm beet 100 e-mails per pagina en zorgt dan dat de pagina automatisch ververst en verstuur je de volgende 100 e-mails, etc. etc.

[DataGhost]

RedBeard schreef op dinsdag 25 april 2006 @ 08:40:
Ik heb ooit ook iets dergelijks gebouwd. Ik weet niet meer exact hoe ik het opgelost heb maar volgens mij ook d.m.v. flush() of ob_flush() hierdoor voorkwam ik de timeout

ik zal even in mijn oude code gaan zoeken of ik het terug kan vinden.

hmm, nu ben ik eens verder gaan denken en uit de TS maak ik op dat de TS IE gebruikt... die wacht volgens mij inderdaad niet, Opera wel daarom heb ik geen flush() nodig om de output al naar de browser te sturen. Helemaal als er nog een header gestuurd gaat worden, de browser ontvangt dan van het script geen of slechts een paar headers en maakt daarna de pagina niet (op tijd) af...
Als het een location header is zou ik hem gewoon vervangen door een stuk javascript, ik kan me verder niet echt een nuttige header voorstellen voor een mailscript.

[johanmulder]

Mocht je toch bezig zijn met het optimaliseren kan je het beste je script ook zo aanpassen dat de mails gebatched de deur uitgaan. Een stroom van 5000 mails van 1 bepaalde server binnen een korte tijd kan snel worden aangezien als Spam. Ik zal iig een loop gebruiken zodat er iedere keer 50 mails worden verstuurd en daarna een seconde pauze inlassen met de aanroep sleep(1); Succes!

[Mr. Bondt]

Kijk anders even hier:
http://pear.php.net/packages.php?catpid=14&catname=Mail

Want wat je nu doet is hoogst inefficiënt, want hij opent een verbinding, stuurt de mail en sluit de verbinding weer

[t-x-m]

johanmulder schreef op dinsdag 25 april 2006 @ 08:52:
Mocht je toch bezig zijn met het optimaliseren kan je het beste je script ook zo aanpassen dat de mails gebatched de deur uitgaan. Een stroom van 5000 mails van 1 bepaalde server binnen een korte tijd kan snel worden aangezien als Spam. Ik zal iig een loop gebruiken zodat er iedere keer 50 mails worden verstuurd en daarna een seconde pauze inlassen met de aanroep sleep(1); Succes!

Ik kreeg vorige week een mailtje van een of andere site(mercilles mod) en die gaven in 1x 79.000 email-adressen weg in het vakje aan, en hij kwam hij gewoon in mn postvak in, het kan dus blijkbaar wel!

[Vinnienerd]

T-X-M schreef op dinsdag 25 april 2006 @ 10:32:
[...]

Ik kreeg vorige week een mailtje van een of andere site(mercilles mod) en die gaven in 1x 79.000 email-adressen weg in het vakje aan, en hij kwam hij gewoon in mn postvak in, het kan dus blijkbaar wel!

Dat kan niet...dan heeft jouw e-mail adres in het BCC veld gestaan.

[JozyDaPozy]

Ik doe dit op de volgenede manier:

zodra je de nieuwsbrief wilt gaan versturen, vul je een mysql-tabel met alle emailadressen (en eventueel andere dynamische data)

Vervolgens maak je een verzenden-pagina die steeds de eerste 100 records pakt, de mails verzend, en die records wist, en dan weer die pagina laadt.

Zo heb je een loopje dat net zolang bezig is, totdat die tabel leeg is.

Ben je meteen van je probleem af dat bij een foutmelding o.i.d. je de kans hebt dat mensen bij een nieuwe probeer-actie een nieuwsbrief 2x krijgen.

[marko77]

Ik heb iets soortgelijks ook meegemaakt in een andere omgeving (Zope & Python).

Ook hier kreeg ik een browser timeout na een bepaalde tijd, echter het script ging dan wél door, maar omdat je dit als gebruiker niet ziet is het niet werkbaar.

Ik heb dit toen opgelost met een aparte mailhost, die draaide op de server als losse daemon. Het script vulde alleen de spool van de daemon en de daemon haalt vervolgens elke x minuten een aantal mails op.

op deze manier kan ik 26000 mails in een uur versturen en de gebruiker is in 2 minuten klaar.

Wellicht is een dergelijke oplossing ook voor de TS bruikbaar, maar het is niet duidelijk of je toegang hebt tot de server e.d.

[chris]

Kijk anders eens in dit topic: [rml][ PHP] Nieuwsbrief naar 4000 adressen: hoe?[/rml], daar heb ik ook uitgelegd hoe ik het doe. Dat was echter voor 4000 mensen, ik weet niet of het ook schaalt naar 5000 adressen

[ Voor 16% gewijzigd door chris op 25-04-2006 11:01 ]

[Verwijderd]

ZeRoXcOoL schreef op dinsdag 25 april 2006 @ 08:46:
Of je verzendt pak 'm beet 100 e-mails per pagina en zorgt dan dat de pagina automatisch ververst en verstuur je de volgende 100 e-mails, etc. etc.

Dat lijkt me idd de meest mail server vriendelijke manier. Gewoon met een LIMIT functie in SQL werken en als parameter aan je refresh tag de nieuwe start offset meegeven.

[flashin]

Kun je het niet gewoon uitvoeren via de shell?


@hierboven: de meeste mailservers horen zoiets makkelijk aan te kunnen hoor

[ Voor 48% gewijzigd door flashin op 25-04-2006 11:45 ]

[Verwijderd]

Ik zeg ook niet dat ze het niet aankunnen, maar het is wat vriendelijker voor je sysload.

En je heb gelijk, mijn eerste gedachte was php -F mailer.php maar goed dat vind niet elke hoster goed en zelfs een exec met een nice mag niet overal.

[BBrunekreeft]

Verwijderd schreef op dinsdag 25 april 2006 @ 11:40:
[...]


Dat lijkt me idd de meest mail server vriendelijke manier. Gewoon met een LIMIT functie in SQL werken en als parameter aan je refresh tag de nieuwe start offset meegeven.

Ik gebruik de Mail_Queue Pear class (http://pear.php.net/package/Mail_Queue) in combinatie met een cronjob. Werkt perfect.