Mailsysteem - xxx per seconde?

[Verwijderd]

Beste Tweakers,

Ik ben bezig met een mail systeem, nu op zo'n manier:

PHP:

$aResult = mysql_query("SELECT email FROM leden WHERE mailing = '1'") or die(mysql_error());
while($aUser = mysql_fetch_assoc($aResult))
{ 
   mail($bla, $subj, $msg, $headers);
   usleep(500000);
}

Is dit te doen als er +- 30.000 e-mails in de database staan?
Iemand tips?

Alvast bedankt!

[ Voor 2% gewijzigd door een moderator op 10-02-2008 15:15 . Reden: Code tags toegevoegd ]

[SeatRider]

Ik zou die usleep(500000) dan wel weglaten

[Verwijderd]

Dat doe ik liever niet, ik laat 'm via een cronjob lopen .
Als ik hem zonder sleep xx.xxx mails laat versturen op een al drukke server dan word mijn server daar niet echt blij van.

[Verwijderd]

De beste manier is om dit een beetje asynchroon aan te pakken. Zet een x aantal mailtjes in de que (dat is wat je over het algemeen doet als je de mail functie aanroept). Elke zoveel tijd, bijvoorbeeld om de paar minuten, kijk je naar het aantal mailtjes in de queue als dat mogelijk is. Dan weet je ook hoeveel mailtjes je in de queue kunt aanvullen zonder dat het uit de klauwen loopt.

Maar op zich heeft dat het laten sleepen van je script niet zoveel nut. Er wordt misschien toch al niet real-time gemaild, dat is zeer afhankelijk van de instellingen van je MTA.

Mocht je de rechten niet hebben om de grootte van de queue in de gaten te houden, zul je aan de veilige kant moeten gaan zitten qua aantal mailtjes per tijdseenheid.

Vergeet niet dat bij zulke grote mailings er veel mailtjes wellicht niet direct lukken, of dat er gebruik wordt gemaakt van greylisting. Als je dan een verschrikkelijk grote queue er op na houdt, zit je met een probleem als je MTA over zijn nek gaat. Je weet dan niet welke mensen wel of geen mailtjes hebben gehad. Het is beter dat te tracken door pas mailtjes eruit te gaan sturen als je weet dat je mailer het aankan.

[RobIII]

@Bulletstar: Again: Waar hoort mijn topic?
SEA >> PRG

En als je code post, gebruik dan code tags

[ Voor 30% gewijzigd door RobIII op 10-02-2008 15:15 ]

[Rob]

Verwijderd schreef op zondag 10 februari 2008 @ 15:12:
Dat doe ik liever niet, ik laat 'm via een cronjob lopen .
Als ik hem zonder sleep xx.xxx mails laat versturen op een al drukke server dan word mijn server daar niet echt blij van.

Houdt dan ook in een database bij wie er al gemaild is, hoe laat etc.
Gaat het 1x mis, dan ben je blij dat dat er in zit

[Verwijderd]

Verwijderd schreef op zondag 10 februari 2008 @ 15:14:
De beste manier is om dit een beetje asynchroon aan te pakken. Zet een x aantal mailtjes in de que (dat is wat je over het algemeen doet als je de mail functie aanroept). Elke zoveel tijd, bijvoorbeeld om de paar minuten, kijk je naar het aantal mailtjes in de queue als dat mogelijk is. Dan weet je ook hoeveel mailtjes je in de queue kunt aanvullen zonder dat het uit de klauwen loopt.

Maar op zich heeft dat het laten sleepen van je script niet zoveel nut. Er wordt misschien toch al niet real-time gemaild, dat is zeer afhankelijk van de instellingen van je MTA.

Mocht je de rechten niet hebben om de grootte van de queue in de gaten te houden, zul je aan de veilige kant moeten gaan zitten qua aantal mailtjes per tijdseenheid.

Vergeet niet dat bij zulke grote mailings er veel mailtjes wellicht niet direct lukken, of dat er gebruik wordt gemaakt van greylisting. Als je dan een verschrikkelijk grote queue er op na houdt, zit je met een probleem als je MTA over zijn nek gaat. Je weet dan niet welke mensen wel of geen mailtjes hebben gehad. Het is beter dat te tracken door pas mailtjes eruit te gaan sturen als je weet dat je mailer het aankan.

Bedankt voor de informatie! hier heb ik wat aan

--

Sorry mod, zag het andere topic daarna pas. excusses.

Rob schreef op zondag 10 februari 2008 @ 15:14:
[...]


Houdt dan ook in een database bij wie er al gemaild is, hoe laat etc.
Gaat het 1x mis, dan ben je blij dat dat er in zit

Slim idee ja, thnx

[siepeltjuh]

Dit zal niet gaan werken.

Standaard staat in PHP.ini ingesteld dat een script maximaal 30 of 60 seconden mag duren.
Dat gaat dus hardstikke mis met dit script.

Zelf zou ik ook kiezen voor een que. Elke 3 minuten ofzo het script aanroepen, indien nodig de que vullen en vervolgens de que legen.

Overigens weet ik niet welke ISP je hebt. Maar 30.000 mails versturen levert via een consumenten lijn zeker weten een BAN op.
Had je waarschijnlijk wel aangedacht, maar wou het voor de zekerheid even noemen.

[Verwijderd]

Ik heb een dedicated server (2)
Zijn er ook sités waar je een maillijst kunt inladen en dan mails kunt versturen?

(uiteraard betaald)

[Verwijderd]

Rob schreef op zondag 10 februari 2008 @ 15:14:

Houdt dan ook in een database bij wie er al gemaild is, hoe laat etc.
Gaat het 1x mis, dan ben je blij dat dat er in zit

Precies. Als er iets fout gaat in je run, is het not done om mensen tweemaal hetzelfde mailtje te laten ontvangen. Dus je moet òfwel heel goed bijhouden in je script naar welke adressen al een poging is ondernomen, òfwel de poging in zijn geheel staken als er iets misgaat. Je kunt dan beter vertrouwen op je "eigen queue", en die niet al te groot laten zijn. In geval het misgaat kun je naar de mensen die al in de batch zijn opgenomen niet meer mailen, maar alle mensen erna nog wel. Als je dus een batch van 100 mailtjes neemt, kun je bij een fout hooguit 100 mensen (per fout) niet meer mailen. Wat belangrijker is, je kunt desnoods jouw cronjob stoppen en eerst de queu van de MTA zien te flushen, en daarna weer ongestoord verder gaan.

[Verwijderd]

siepeltjuh schreef op zondag 10 februari 2008 @ 15:22:
Dit zal niet gaan werken.

Standaard staat in PHP.ini ingesteld dat een script maximaal 30 of 60 seconden mag duren.
Dat gaat dus hardstikke mis met dit script.

Processortijd. En je kunt die zelf verhogen door set_time_limit aan te roepen. En voor dit soort scripts is dat heel normaal.

[Milt]

De mail() functie van PHP is niet echt geschikt voor grote hoeveelheden mail. Volgens mij praat mail() rechtstreeks met de SMTP server voor het versturen van de mail. Je kunt beter bijvoorbeeld PEAR::Mail gebruiken. Bevat alles wat je nodig hebt en kan ook vanuit een cron job worden gebruikt.

[FragFrog]

Verwijderd schreef op zondag 10 februari 2008 @ 15:26:
Ik heb een dedicated server (2)
Zijn er ook sités waar je een maillijst kunt inladen en dan mails kunt versturen?

(uiteraard betaald)

Voor een klant een keer een integratie geschreven met graphicmail, die hebben een best leuke API, zijn gratis te testen en hebben verdraaid leuke servers speciaal voor dit soort ongein

Daarnaast, met hierboven, PHP's standaard mail() functie wil je niet gebruiken voor grote mailings, daar is'ie simpelweg niet voor bedoeld.

[Verwijderd]

Als je cron gebruikt, dan roep je je PHP aan via commandline, dan heb je ook geen tijdlimit!

[ Voor 5% gewijzigd door Verwijderd op 10-02-2008 21:55 ]

[Cartman!]

Of een oplossing zonder cronjobs als je host het niet toe laat. Gebruik PHPMailer of de Mail class van PEAR zoals Milt al aangaf. Je maakt een php file die een x aantal (bijv. 100) mails verstuurd die nog op niet verstuurd staan in de database (via een flag '0'). De mails die verstuurd zijn flag je ('1') zodat ze niet nogmaals verstuurd kunnen worden.
Om dit aan te roepen pak je een html pagina die via een AJAX request de php file aanroept. Als return functie roep je met een vertraging van een x aantal seconden weer de AJAX request aan zodat er weer gemaild wordt. Als je het script een bepaalde waarde laat returnen als hij klaar is met alle mails dan stop je de recursieve aanroep.

[frickY]

mail() staat continue te connecten, te handshaken en te disconnecten met je SMTP server. Dat maakt bij 3 mailtjes niet uit, maar zorgt bij >10 voor enorme overhead.

Je wilt liever met fsockopen zelf verbinden naar je mailserver .Verdiep je even in het protocol en je schrijft zo je eigen implementatie die een stuk sneller loopt, en waar je ook de status van je mailserver in kunt afvangen.

[Creepy]

siepeltjuh schreef op zondag 10 februari 2008 @ 15:22:
Dit zal niet gaan werken.

Standaard staat in PHP.ini ingesteld dat een script maximaal 30 of 60 seconden mag duren.
Dat gaat dus hardstikke mis met dit script.

Zelf zou ik ook kiezen voor een que. Elke 3 minuten ofzo het script aanroepen, indien nodig de que vullen en vervolgens de que legen.

Overigens weet ik niet welke ISP je hebt. Maar 30.000 mails versturen levert via een consumenten lijn zeker weten een BAN op.
Had je waarschijnlijk wel aangedacht, maar wou het voor de zekerheid even noemen.

Dat script loopt via een cronjob. Als je via je cronjob de CLI versie van PHP aanroept dan heb je vnauit PHP niks te maken met een timeout/max execution time. Als je de mogelijkheid hebt om php via de commandline aan te roepen vanuit een cronjob ga dan niet lopen rommelen met een script dat via een URL aangeroepen moet worden die wel zo'n max execution time heeft.

[Verwijderd]

FragFrog schreef op zondag 10 februari 2008 @ 21:51:

Daarnaast, met hierboven, PHP's standaard mail() functie wil je niet gebruiken voor grote mailings, daar is'ie simpelweg niet voor bedoeld.

Ik durf best te beweren dat dat onzin is. Op een machine met een goed geconfigureerde MTA kun je prima op die mail functie vertrouwen. Zo niet, moet je maar eens aangeven waarop het stukloopt.

[FragFrog]

Verwijderd schreef op maandag 11 februari 2008 @ 00:03:
Ik durf best te beweren dat dat onzin is. Op een machine met een goed geconfigureerde MTA kun je prima op die mail functie vertrouwen. Zo niet, moet je maar eens aangeven waarop het stukloopt.

frickY schreef op zondag 10 februari 2008 @ 22:22:
mail() staat continue te connecten, te handshaken en te disconnecten met je SMTP server. Dat maakt bij 3 mailtjes niet uit, maar zorgt bij >10 voor enorme overhead.

En daar komt bij dat mail() simpelweg erg gelimiteerd is. Als je iets als pear::Mail gebruikt kun je veel eenvoudiger mailtjes sturen, die bovendien in mijn ervaring een stuk simpeler zo in te stellen zijn dat ze niet automatisch in je hotmail spambox gekiepert worden.

En ja, natuurlijk, het kan wel, hell, je kan ook alle mailtjes uitprinten en door een typemiep in outlook laten versturen. Punt is dat er betere oplossingen zijn

Daarnaast heeft ondertussen elke sjaak en z'n oma een aparte techniek om spam tegen te gaan geschreven, al die whitelists / greylists / headers / etc bijhouden is een complete dagtaak. Als er dan een budget voor is ben je nog het allersimpelst af door die het fijn allemaal te laten regelen

[ Voor 12% gewijzigd door FragFrog op 11-02-2008 01:00 ]

[BBrunekreeft]

Milt schreef op zondag 10 februari 2008 @ 21:39:
De mail() functie van PHP is niet echt geschikt voor grote hoeveelheden mail. Volgens mij praat mail() rechtstreeks met de SMTP server voor het versturen van de mail. Je kunt beter bijvoorbeeld PEAR::Mail gebruiken. Bevat alles wat je nodig hebt en kan ook vanuit een cron job worden gebruikt.

Gebruik dat dan in combinatie met PEAR:Mail_Queue.
Daarmee zet je al je mailtjes meteen in een queue (database). Vervolgens kun je met dezelfde package die queue weer verzenden, met een x aantal mailtjes per keer (d.m.v. een cronjob). Gebruik het hier zelf om ongeveer 40.000 mails te versturen. Gaat perfect.

[AndriesLouw]

Ik zelf zet alle e-mails klaar in de database (to, subject, message, headers), en laat een cronjob elke minuut 50 versturen (om deze 50 vervolgens af te vinken in de database, een soort kolom "sended" ). Ik sla hierbij ook gelijk de status op, zo kan ik altijd zien of een mail wel, of niet verzonden kon worden.

[BikkelZ]

Meestal is het in een keer doorpompen van 30.000 mails ineens een Slecht Idee. Gewoon niet meer dan 50 tegelijk, en dan je cron zo instellen dat hij deze zo goed mogelijk over 24 uur uitsmeert.

[Kettrick]

Als je al 30K mails wilt versturen kan je dit beter overlaten aan een pakket dat hiervoor gemaakt is. googlen op mailing list manager geeft genoeg hits. ezmlm of majordomo bijvoorbeeld zorgen er ook voor dat mensen zich kunnen afmelden.

Je hoeft dan zelf niet in te zitten over queuing e.d.

[sig69]

AndriesLouw schreef op maandag 11 februari 2008 @ 10:26:
een soort kolom "sended" . Ik sla hierbij ook gelijk de status op, zo kan ik altijd zien of een mail wel, of niet verzonden kon worden.

[mierenneukmodus]sended -> sent
En "sent" is een status op sich natuurlijk, dus aan die status kolom had je genoeg gehad[/mierenneukmodus]

[curry684]

Verwijderd schreef op zondag 10 februari 2008 @ 15:28:
[...]

Processortijd. En je kunt die zelf verhogen door set_time_limit aan te roepen. En voor dit soort scripts is dat heel normaal.

Uitgaande van dat je zonder safe_mode draait.

[Kettrick]

curry684 schreef op maandag 11 februari 2008 @ 17:27:
[...]

Uitgaande van dat je zonder safe_mode draait.

TS geeft aan over twee dedicated servers te beschikken, safe_mode lijkt me geen probleem dus

tenzij je het leuk vindt jezelf tegen te werken, dan wel

[Milt]

@RoeLz: Een mailinglist manager is veelal geen optie. Dan stuur je namelijk naar iedereen hetzelfde mailtje en veelal wil je gepersonaliseerde e-mails sturen.

@Cheatah: Op UNIX systemen roept mail() voor iedere e-mail sendmail (of een andere geconfigureerde) MTA aan en op Windows levert mail() de mail direct af bij een geconfigureerde SMTP server. Dit gaat mailtje voor mailtje. Niet echt efficient. Het is handiger en sneller om de mails direct naar een queue te schrijven waar een MTA ze uit kan lezen.