[PHP] Nieuwsbrief naar 4000 adressen: hoe?

[BlueAce]

Voor een klant ben ik bezig met een nieuwsbriefsysteem. Hier zou een HTML-mail verstuurd moeten worden naar ongeveer 4000 verschillende adressen, met daarbij een paar PDF's (hoezeer ik het ze ook afraadt, dat is een lange discussie geweest die ik hier niet zal herhalen).

Het probleem is echter dat PHP vastloopt als ik een verzending doe. Ik weet dat het niet aan mijn code ligt, want als ik verzend naar 100 man dan krijgt iedereen gewoon netjes de mail in zijn inbox. Grotere getallen dan dat en ik krijg alleen na 5 minuten laden een wit scherm te zien, wat volgens mij inhoud dat PHP het voor gezien houdt en vastloopt. De max_execution_time staat op 0 (unlimited dus), dus dat is het niet.

Ik gebruik hiervoor de PHPMailer class.

Heeft iemand hier ervaring mee? Moet ik de mails in batches gaan versturen? Moet ik een SMTP server gaan koppelen aan die PHPMailer class? Of moet ik een andere class gebruiken?

[aex351]

Misschien onderstaand functie gebruiken

PHP:

sleep()

[Sybr_E-N]

Dat je script stopt kan ook te maken hebben dat de gereserveerde aantallen megabytes voor een PHP-script wordt bereikt. Standaard staat die geloof ik ingesteld op 8 megebyte. Moet het perse met PHP worden opgelost, het versturen van duizenden emailtjes?

[prototype]

Het helpt als je wat van je code laat zien. Ik zou je in ieder geval aanraden om te debuggen (i.e. de huidige staat printen) na elke iteratie.

Ik vermoed dat je voor elke mail een object hebt gemaakt en deze nadat je ermee klaar bent niet hebt gede-alloceerd waardoor je geheugen tekort komt tov je php instellingen, maar daar kunnen we pas zeker van zijn als je wat code post.

[ Voor 46% gewijzigd door prototype op 08-12-2005 19:58 ]

[frickY]

Waarschijnlijk maakt phpMailer gewoon gebruikt van de mail()-functie van PHP. Dat houd in;
Voor elke e-mail die wordt verstuurd wordt een socketverbinding naar de SMTP-server geopent, het bericht naar de SMTP server gestuurd, en de verbinding weer gesloten.
Als je die 4000x achter elkaar doet kun je ervan uit gaan dat de server op zijn bek gaat.

Ik raad je aan zelf een functie te schrijven welke verbind naar de SMTP server (fsockopen()), alle mails overpompt, en dan de verbinding weer sluit. Je zult je even moeten inlezen in het protocol maar het is een leuke en leerzame oevening

[djluc]

frickY schreef op donderdag 08 december 2005 @ 20:00:
Waarschijnlijk maakt phpMailer gewoon gebruikt van de mail()-functie van PHP. [...]

Dat is inderdaad mogelijk maar een socket is ook mogelijk met die class.

[ShadowLord]

BlueAce schreef op donderdag 08 december 2005 @ 19:48:
Grotere getallen dan dat en ik krijg alleen na 5 minuten laden een wit scherm te zien, wat volgens mij inhoud dat PHP het voor gezien houdt en vastloopt. De max_execution_time staat op 0 (unlimited dus), dus dat is het niet.

Ik maak hieruit op dat je je script vanuit je browser aanroept (wit scherm)? Na 5 minuten niets gehoord te hebben geeft je browser het waarschijnlijk gewoon voor gezien 'page not found', 'empty document returned', oid.
Ik weet niet of PHP dan ook stopt (de browser killed de connectie), maar grote kans. Probeer dan ook je script eens van de command-line aan te roepen. Dan krijg je in ieder geval geen timeout.

[TheDane]

phpMailer kan ook met CC en BCC overweg. Helpt dat niet?

4000 keer een phpMailer() instantie aanmaken helpt ook niet veel. Weet niet of dat de oorzaak is, maar -uit eigen ervaring - word je daar niet vrolijk van

Misschien kun je je mail process nog forken.

[flashin]

IDD, de inhoud van die nieuwsbrief gewoon standaard houden (dus geen dynamische namen) en dan gewoon BCC'en die hap.

[frickY]

Met een socket-verbinding is dit prima te doen hoor, heb zo duizenden gepersonaliseerde nieuwsbrieven verstuurd.

@ShadowLord
Zie ignore_user_abort();

[Creepy]

En ga aub niet CC'en en BCC'en. Dat wordt vaak al flink in aantal beperkt en verhoogt de kans dat je mail in de spamfilter terecht komt..

Stuur elke mail los. 4000 mails kan een beetje mailserver echt wel aan . Uiteraard wel een eigen mailserver gebruiker want als je zomaar 4000 mails op de mailserver van je provider afvuurt gaan die niet echt blij worden

Waarschijnlijk kan je beter het via PHP CLI versturen want dan heb je geen last van zaken als max execution time e.d.

[prototype]

Ik heb net even de sourcecode bekeken van die mailerclasse, en je hebt idd de optie uit diverse methoden om de mail uiteindelijk de deur uit te schoppen, respectievelijk sendmail, php mail() en smtp. Zoals frickY al zei kan het liggen aan het feit dat je 4000 individuele mails via mail() probeert te verzenden, en dus 4000x een TCP connectie opent en sluit en dan je ding doet, dat nogal belastend is. Wat je beter kan doen dan idd, is via SMTP, i.e. in 1 request (dus 1 TCP connectie) ervoor zorgen dat alle mail gepushed wordt. Volgens mij maakt de classe het nog dermate makkelijk voor je door het protocol al voor je te implementeren, anders moet je je er even in verdiepen.

[ Voor 14% gewijzigd door prototype op 08-12-2005 21:19 ]

[El_kingo]

Creepy schreef op donderdag 08 december 2005 @ 21:08:
En ga aub niet CC'en en BCC'en. Dat wordt vaak al flink in aantal beperkt en verhoogt de kans dat je mail in de spamfilter terecht komt..

Stuur elke mail los. 4000 mails kan een beetje mailserver echt wel aan . Uiteraard wel een eigen mailserver gebruiker want als je zomaar 4000 mails op de mailserver van je provider afvuurt gaan die niet echt blij worden

Waarschijnlijk kan je beter het via PHP CLI versturen want dan heb je geen last van zaken als max execution time e.d.

Hele goede oplossing, kleine aanvulling:
Doe de mailserver ook een lol en gebruik een eigen verbinding (via fsockopen o.i.d) en geef (voor mijn part in batches) gewoon meerdere RCPT TO: regels op naar de smtp server. smtp servers moeten in ieder geval 100 adressen cachen... Dat betekend dat (met een klein beetje trail and error) maar een paar keer je bericht + attachements naar je mail server hoeft te versturen...

Jij blij, mail server blij...

[GX]

Ik maakte meestal een "mailqueue" in m'n dataopslag (vaak database of plain text), en een refresh scriptje op de pagina welke om de zoveel seconde een mailtje de deur uit flikkert. Het duurt even, maar het werkt wel, en als de mailing halverwege zomaar stopt kan je het gewoon hervatten.

[Teak]

GX schreef op donderdag 08 december 2005 @ 21:56:
Ik maakte meestal een "mailqueue" in m'n dataopslag (vaak database of plain text), en een refresh scriptje op de pagina welke om de zoveel seconde een mailtje de deur uit flikkert. Het duurt even, maar het werkt wel, en als de mailing halverwege zomaar stopt kan je het gewoon hervatten.

Gebruik een beetje dezelfde methode. Alleen laat ik de mailtjes per 10/20/30/40/50 gaan. En dan 10 seconde rust. En dan de volgende zoveel. Op deze manier ben je wel even bezig. Maar je laat je scherm open staan en hij gaat automatisch verder zodat je gewoon kan doorwerken.

[Nijl]

zit je mail wel in een loop ?een for each?

of druk je ze in 1 x door je phpmailer ? (gebruik ik zelf namelijk ook )

[BasieP]

misschien een andere oplossing:
een javascript referer, die na 10 secs refered naar een adres als:
mail.php?vanaf=100

en die dan 100 mails stuurt en na 10 secs refered naar mail.php?vanaf=200
zo roep je php niet 1x aan met een mega taak, maar meerdere malen, met wat fatsoenlijkere taken

dis niet echt een nette oplossing, maar het werkt waarschijnlijk wel
houd maar achter de hand ofzo

[prototype]

BasieP schreef op donderdag 08 december 2005 @ 23:13:
misschien een andere oplossing:
een javascript referer, die na 10 secs refered naar een adres als:
mail.php?vanaf=100

en die dan 100 mails stuurt en na 10 secs refered naar mail.php?vanaf=200
zo roep je php niet 1x aan met een mega taak, maar meerdere malen, met wat fatsoenlijkere taken

dis niet echt een nette oplossing, maar het werkt waarschijnlijk wel
houd maar achter de hand ofzo

Ja en wat nou als je server op dat ene moment net niet bereikbaar is. Dan gaat je javascript vrolijk verder door de offset te verhogen zonder enige 'controle' dat de vorige mailtjes al verzonden zijn, of kapt er totaal mee, afhankelijk van hoe je het implementeert.
De beste oplossing is nu al meerdere keren mijns inziens geopperd, door een tcp connectie te bewerkstelligen en dan via je socket SMTP praten tegen de server, of nog makkelijker gewoon smtp verzend methode gebruiken bij die PHPMailer classe, die schijnbaar al SMTP voor je praat.

[BlueAce]

prototype schreef op donderdag 08 december 2005 @ 21:16:
Ik heb net even de sourcecode bekeken van die mailerclasse, en je hebt idd de optie uit diverse methoden om de mail uiteindelijk de deur uit te schoppen, respectievelijk sendmail, php mail() en smtp. Zoals frickY al zei kan het liggen aan het feit dat je 4000 individuele mails via mail() probeert te verzenden, en dus 4000x een TCP connectie opent en sluit en dan je ding doet, dat nogal belastend is. Wat je beter kan doen dan idd, is via SMTP, i.e. in 1 request (dus 1 TCP connectie) ervoor zorgen dat alle mail gepushed wordt. Volgens mij maakt de classe het nog dermate makkelijk voor je door het protocol al voor je te implementeren, anders moet je je er even in verdiepen.

Dit lijkt mij de beste oplossing. Ik ga het nu implementeren en hou jullie op de hoogte. Bedankt

Overigens even voor de duidelijkheid: nee, ik maak niet 4000 keer een mailerclass aan. Please... De code heb ik volledig geoptimaliseerd zodat niets meerdere keren wordt gedaan, behalve de inhoud van het mailtje customizen en daarna versturen.

[Arto]

prototype schreef op donderdag 08 december 2005 @ 23:25:
[...]

Ja en wat nou als je server op dat ene moment net niet bereikbaar is. Dan gaat je javascript vrolijk verder door de offset te verhogen zonder enige 'controle' dat de vorige mailtjes al verzonden zijn, of kapt er totaal mee, afhankelijk van hoe je het implementeert.
De beste oplossing is nu al meerdere keren mijns inziens geopperd, door een tcp connectie te bewerkstelligen en dan via je socket SMTP praten tegen de server, of nog makkelijker gewoon smtp verzend methode gebruiken bij die PHPMailer classe, die schijnbaar al SMTP voor je praat.

ik denk dat hij bedoelt dat javascript als het script afgelopen is, alleen het probleem is dat als er ergens een error komt dat ie halverwege stopt en een error geeft maar niet verder gaat, maar dat probleem zul je altijd tegen kunnen komen, zeker via php

[Verwijderd]

Ik denk dat je twee oplossingen voor dit probleem kunt bedenken:

1. Je opent een ruwe connectie direct naar een SMPT-server. Hiervoor zijn klassen beschikbaar in PHP (GIYOTF: Google Is Your Only True Friend). Doordoor hoef je niet 4000+ connecties te openen maar kun je de mail direct naar de SMTP zenden.

2. Ajax. Maak een client-side js-script dat naar een PHP-script post met daarin de offsets. Het hierboven genoemde probleem van checking wordt afgehandeld doordat je client-side kunt wachten op de response van de server. Op deze manier zal je client-side script enkel een nieuwe post doen wanneer de vorige (bijvoorbeeld) 100 verzonden zijn en de server een response heeft gegeven.

Het lijkt me duidelijk dat oplossing 1 een gestructureerdere oplossing is, maar vergt wel wat meer kennis dan oplossing 2.

[FunzoneQ!]

Het is niet zozeer phpmailer, maar meer je mailserver.

Ik ram er via PHPmailer en Qmail zo 33.000 mails uit in 45 minuten. Als je geen max_execution_time wil hebben, moet je gewoon via shell uitvoeren.

/usr/local/bin/php /path/naar/file.php

[Verwijderd]

FunzoneQ! schreef op vrijdag 09 december 2005 @ 10:58:
Ik ram er via PHPmailer en Qmail zo 33.000 mails uit in 45 minuten.

Pssst, spamlijst kopen

[Gods Lonely Man]

Creepy schreef op donderdag 08 december 2005 @ 21:08:En ga aub niet CC'en en BCC'en. Dat wordt vaak al flink in aantal beperkt en verhoogt de kans dat je mail in de spamfilter terecht komt..

Hoe kom je dan in de spamfilter terecht? Bij de verzendende mailserver?
Ik dacht altijd dat als je BCC emails via php naar een mailserver stuurd hij er automatische gewoon allemaal losse mailtjes van maakte en dus eigenlijk precies hetzelfde resultaat oplevert als wanneer je ze allemaal per stuk zou versturen.

En de ontvangende partij merkt er toch helemaal niets van of er 2 of 10.000 BCC-adressen in staan?

Of heb ik het nu weer eens helemaal fout ?

[BlueAce]

FunzoneQ! schreef op vrijdag 09 december 2005 @ 10:58:
Als je geen max_execution_time wil hebben, moet je gewoon via shell uitvoeren.

Ik heb helaas geen shell-access, en daarnaast moet het niet de bedoeling zijn dat ik zelf de verzending doe maar de klant.

[Verwijderd]

PsychoBoy schreef op vrijdag 09 december 2005 @ 11:37:
[...]
Of heb ik het nu weer eens helemaal fout ?

Een beetje denk ik. Natuurlijk wordt een mailtje per adres verstuurd door de uitgaande server, maar het punt is welke informatie er in welke header komt te staan. Wanneer je een BCC stuurt betekend dit dat de email niet aan jou gericht is, en komt je niet in de 'To' header te staan. Dit is iets waar spamfilters over kunnen vallen.

[Creepy]

PsychoBoy schreef op vrijdag 09 december 2005 @ 11:37:
[...]

Hoe kom je dan in de spamfilter terecht? Bij de verzendende mailserver?
Ik dacht altijd dat als je BCC emails via php naar een mailserver stuurd hij er automatische gewoon allemaal losse mailtjes van maakte en dus eigenlijk precies hetzelfde resultaat oplevert als wanneer je ze allemaal per stuk zou versturen.

En de ontvangende partij merkt er toch helemaal niets van of er 2 of 10.000 BCC-adressen in staan?

Of heb ik het nu weer eens helemaal fout ?

Als je alleen verstuurd aan een BCC lijst zonder het "aan" veld te gebruiken dan gaat je spam score omhoog. Ook als je verzend met een wel ingevuld "aan" veld maar de rest met de BCC stuurt dan krijgt de ontvanger niet zichzelf te zien in het "aan" veld. Ook dit verhoogt de kans om te worden aangemerkt als spam.

Dit levert dus wel degelijk een ander resultaat op dan alle mails daadwerkelijk los te versturen.

Edit: wat sKILL4 dus ook zegt

[ Voor 6% gewijzigd door Creepy op 09-12-2005 12:47 ]

[Gods Lonely Man]

Creepy schreef op vrijdag 09 december 2005 @ 12:46:Als je alleen verstuurd aan een BCC lijst zonder het "aan" veld te gebruiken dan gaat je spam score omhoog. Ook als je verzend met een wel ingevuld "aan" veld maar de rest met de BCC stuurt dan krijgt de ontvanger niet zichzelf te zien in het "aan" veld. Ook dit verhoogt de kans om te worden aangemerkt als spam.

Hmm, okee klinkt opzich wel logisch.

Maar dat zou betekenen dat je ook normale BCC via outlook niet mag gebruiken? Want bijvoorbeeld hier op kantoor of vroeger op school werden bijna alle emails met een BCC erbij (en dan natuurlijk ook nog een normale ontvanger erbij) verzonderen. Dan zou dat toch ook als spam worden aangemerkt of is het dan weer anders?

[Creepy]

Een hogere score wat betreft spam is heel iets anders dan als spam worden aangemerkt

[BlueAce]

Nou het is me gelukt, voornamelijk dankzij deze opties in de PHPMailer class:

PHP:

$mail->Host = "mail.xxxx.net";
$mail->Mailer = "smtp";       
$mail->SMTPKeepAlive = true;

En dan verderop een SmtpClose(). Maar toch duurt het enorm lang voordat het PHP bestand volledig geladen is, en bij sommige adressen krijg ik een foutmelding terug:

The following From address failed: [e-mail]

Geen idee wat dit betekend, maar het gebeurt wel periodiek raar genoeg.

[ Voor 13% gewijzigd door BlueAce op 09-12-2005 13:50 ]

[SnoW]

Zijn javascript-oplossingen (al dan niet met ajax) niet veel te omslachtig, als je gewoon ignore_user_abort() kunt gebruiken? (zoals frickY al opperde)

[Enfer]

Moet het mailen per se via php gaan?
Anders kun je namelijk ook de emailadressen voor de nieuwsbrief opslaan in een outlook bestand, en die importeren en vanuit outlook de mail sturen?

[joopv]

Draait dit op een XPsp2 doos?
Zo ja, dan moet je er aan denken dat er maximaal 10 TCP (smtp) connects in opbouw kunnen staan.

Kijk even in je system event log of je event ID 4226 tegenkomt.

[djluc]

Problem? schreef op vrijdag 09 december 2005 @ 16:08:
Moet het mailen per se via php gaan?
Anders kun je namelijk ook de emailadressen voor de nieuwsbrief opslaan in een outlook bestand, en die importeren en vanuit outlook de mail sturen?

Dat hebben wij ook een tijdje gedaan maar is niet handig. Zo heb je geen statistieken van welke mails wel/niet verstuurd zijn enzovoorts.

[chris]

Ik lees het topic nu pas, en er is een oplossing, maar misschien dat je hier ook nog wat aan heb. Ik moet ook nieuwsbrieven aan > 10000 mensen versturen. Ik heb het zo opgelost:

Op het moment dat er op "send newsletter" wordt gedrukt, wordt er voor iedere ontvanger een row aangemaakt in de tabel mail_queue, met het subject, de ontvanger, de from: en de html en plaintext. Vervolgens heb ik een cronjob die iedere minuut checkt of er nog rijen in die tabel staan, en zo ja: mail de eerste 50 mensen en verwijder deze uit de db.

Dit zorgt voor een lage load, het kan wel even duren voordat er 10000 mailtjes zijn verstuurd (3,3 uur), maar je weet wel behoorlijk zeker dat de server niet over z'n nek gaat, en dat was in dit geval het belangrijkste probleem.

[We Are Borg]

mooie oplossing chris, zoiets ga ik ook invoeren voor mijn newsletter, thanks

[ Voor 6% gewijzigd door We Are Borg op 10-12-2005 11:02 ]

[djluc]

We Are Borg schreef op zaterdag 10 december 2005 @ 11:02:
mooie oplossing chris, zoiets ga ik ook invoeren voor mijn newsletter, thanks

Leuke oplossing inderdaad, eigenlijk beter dan de huidige oplossing die we nu gebruiken. Verwijder je alle records? Of vink je ze af zodat je een soort van logboek hebt?

[Verwijderd]

djluc schreef op zaterdag 10 december 2005 @ 11:31:

Leuke oplossing inderdaad, eigenlijk beter dan de huidige oplossing die we nu gebruiken. Verwijder je alle records? Of vink je ze af zodat je een soort van logboek hebt?

Uiteraard moet je gewoon alle records bewaren, zo kun je altijd nagaan aan wie een mail al verstuurd is, en deze informatie later nog eens gebruiken.

Overigens gaan wij voor een iets andere oplossing: een mailings tabel, een lists tabel en een members tabel. Met koppeltabellen houd je bij wie welke mailings gaat krijgen (op basis van mailing lists waarop ze zijn ingeschreven) en wie welke mailings al gehad heeft (per user) en wanneer. Uiteraard nog wat gegevens als "deze member wil geen mailings meer ontvangen", want dat is geen reden om informatie uit je database te verwijderen.

Nog iets ingewikkelder: een mailing kan in diverse talen worden gedaan, en elke member heeft een voorkeurstaal, en zal de mailing in de juiste taal ontvangen. Dit is voor een ééntalig systeem niet interessant.

En uiteindelijk is er één script dat elke paar minuten aangeroepen wordt, dat kijkt wie welke mailings nog moet ontvangen, en daarbij wordt natuurlijk gecontroleerd dat de mailing nieuwer moet zijn dan een member, en nog wat dergelijke eenvoudige voorwaarden. En in de query die dat script gebruikt kun je heel simpel een limiet bouwen.

[ Voor 4% gewijzigd door Verwijderd op 10-12-2005 11:40 ]

[chris]

Verwijderd schreef op zaterdag 10 december 2005 @ 11:39:
[...]

Uiteraard moet je gewoon alle records bewaren, zo kun je altijd nagaan aan wie een mail al verstuurd is, en deze informatie later nog eens gebruiken.

Uiteraard ligt dat helemaal aan je toepassing: ik gooi ze weg, ik heb geen zin om wekelijks 10000 records te laten staan. Voor dit bedrijf is het niet nodig om te onthouden aan wie de mail is verstuurd, dat kunnen ze ook nagaan aan de hand van andere informatie. In de werkelijkheid is mijn oplossing net iets ingewikkelder, maar ik denk dat het idee nu wel duidelijk is.

[Rodyman]

chris schreef op zaterdag 10 december 2005 @ 12:10:
[...]

Uiteraard ligt dat helemaal aan je toepassing: ik gooi ze weg, ik heb geen zin om wekelijks 10000 records te laten staan. Voor dit bedrijf is het niet nodig om te onthouden aan wie de mail is verstuurd, dat kunnen ze ook nagaan aan de hand van andere informatie. In de werkelijkheid is mijn oplossing net iets ingewikkelder, maar ik denk dat het idee nu wel duidelijk is.

Zo'n systeem heb ik ook ooit gebouwd voor een bedrijf, werkt perfect, snel, betrouwbaar en de mailserver gaat er niet van over de zeik.
Lijkt me de beste oplossing dus..

[ Voor 4% gewijzigd door Rodyman op 10-12-2005 13:53 ]

[megamuch]

het is dan wel p&w en we schrijven hier zelf de apps, maar je zou eens kunnen kijken naar Sendstudio.

http://www.interspire.com/sendstudio/

Doet het prima voor mijn mailinglistjes. Kost ff wat tijd om het helemaal door te krijgen, maar uiteindelijk erg eenvoudig.