Newsletter an tausende Empfänger

Nucleon

Mitglied
N'Abend Leute,

meine Schülercommunity e-Hausaufgaben.de hat mittlerweile die 100.000-Mitglieder-Marke geknackt und ich verzweifle regelmäßig beim Versenden großer Mengen an Mails, wie beispielsweise dem Newsletter.

Server: Apache/2.2.0 (Linux/SUSE)

Das Problem ist, dass ich zur Zeit den personalisierten HTML-Newsletter mit PHP und mail() verschickte. Da schaffe ich ca. 400 Mails, bevor das Skript nach 300 Sekunden ein Timeout hat. Also lasse ich über mehrere Tage einen Cronjob laufen, der alle paar Minuten ein paar Mails verschickt. Ziemlich blöde Lösung, da es viel zu lange dauert und eine Menge Serverleistung beansprucht.

Ich kann mir nicht vorstellen, dass nun eine Software wie z.B. supermailer.de dieses Problem einfach umgehen kann.


Wie kann ich dieses Problem lösen?

Brauche bitte eure Hilfe
smile.gif



Vielen Dank und einen schönen Abend noch,
Lukas
 
Wenn du es auf einer Weboberfläche machen willst muss sich die Seite per Javascript immer wieder selbst aufrufen und da weiter machen wo sie beim letzten Aufruf aufgehört hat. Vielleicht kannst du auch einen Mailverteiler einrichten, ich meinte dem sollte egal sein um wie viele Adressen es sich handelt.
 
Ich halte den Versand über PHP einfach für unbrauchbar in diesem Fall, da ändert auch die Software/Oberfläche nichts.
Und ein Verteiler bringt mir nichts, da die Mails individualisiert sind und auch sein sollen.
 
Google mal nach "Mail Exploder". Ich hatte vor jahren (etwa 10 sind's schon) ein ähnliches Problem. Wir haben dann einen "Mail Exploder" unter HP-UX 9.x eingerichtet und der hat dann monatlich einige zug-tausend Mails versandt und zwar schön eines nach dem anderen.

Cheers, René
 
am sinnvollsten wäre hier eine eigene mail queue (z.b. auf datenbank basis) die dann von einem (oder später auch mehreren) daemon(s) (in welcher sprache auch immer) abgearbeitet wird.

man kann ggf auch auf einen dienstleister ausweichen (was bei der anzahl an mails imho aber eher noch nicht so lohnt)
 
Hallo,

ich denke, wenn das Script wirklich nach 300s abbricht, handelt es sich um ein Problem mit der PHP Konfiguration. Einfach mal in der php.ini gucken und nach den Einstellungen für TimeOut und Scriptlaufzeit suchen.

 
ich selbst habe auch ein paar newsletter zu versenden die an mehr als 80k adressaten geht. hier in diesem forum wurde mir SuperMailer empfohlen. (www.supermailer.de) Die Paar euro waren wirklich eine gute Investition...
 
Wir haben auch supermailer im Einsatz. Versenden zwar nicht soviele Mails, aber das Tool kann ich nur empfehlen.
 
> Wie kann ich dieses Problem lösen?

0,75 Sekunden pro Mail sind definitiv viel zu viel. Aber evtl. ist nicht die Mailfunktion bzw. der Mailserver das Problem, sondern der Teil der den Newsletter erstellt? Du schreibst ja, dass sie personalisiert sind. Ich komme mit einem ultra-personalisierten Newsletter mit PHP und mail() auf ca 0,03 Sekunden/Mail.
Ich würde erstmal den Script zerfitzeln und schauen wo der Engpass ist.
 
Ich habe folgende Ideen zur Lösung:

- max. Skriptausführungszeit verlängern in der php.ini
--- bleibt immernoch das Problem der Browser Timeouts, wenn mans über ne Web Oberfläche ausführt

- per Cronjob ausführen lassen (nur einmal!) + normale Skriptausführungszeit beibehalten + Selbstaufruf mit header()
--- das Versenden Skript ruft sich nach einer Anzahl von verschickten mails per header() selbst auf
--- das Versenden Skript muss sich die Position merken an die es zuletzt gesendet hat vor header() Aufruf und dann ab da weiter versenden

 
Marc, das kostet aber...

An die früheren Poster: Scripttimeout ist auf jeden Fall sinnvoll. Sonst können unglückliche Umstände euren Server lahmlegen.

Ich habe das selbst gelöst, indem ich eine Kombination aus mysql, php und cronjob gemacht habe. Ich bediene damit ca. 45000 adressaten.

So sieht das circa aus (nagelt mich nicht fest, ich erkläre nur schnell wie ich das skript aufgebaut habe, vielleicht fehlen details):

TABLE: mail
- Mail-ID
- Mail-Text
- Mail-SQL (sql-query, die für die wahl der e-mail adressen verwendet wird)
- Mail-count (Mitgliedernummer, bei der der Mailer angekommen ist) - meine mitglieder haben steigende nummern
- Mail-status (1: aktiv; 0: inaktiv)
- Mail-Priorität

PHP-mail-admin
- Mail erstellen, löschen (text, SQL)
- Mail-Status auf 1 oder 0 setzen
- (autom.) Mail-count bei neuen Mails auf 0
- Manuelle anpassung des mail-counts (z.B. wg. unterbruch des scripts, evtl. um den "*" zu löschen), und das script nochmal anzustossen.

PHP-mailer
- welche mailings sind aktiv? wenn keine, dann exit
- laden aktuelle mitgliedernummer, wenn enthält = *, dann in arbeit, exit
- mailing mit höchster priorität auswählen (höchste prio und tiefste mail-ID)
- SQL ausführen, ORDER ASC by Mitgliedernummer wo Mitgliedernummer < letzte Mitgliedernummer+300 and > letzte mitgliedernummer, LIMIT 300.
- set mitgliedernummer to "letzte mitgliedernummer."*"
- Mail loop: senden aller 300 mails, immer setzen letzte mitgliedernummer++."*"
- Bei Ende: "*" von der aktiven mitgliedernummer löschen.
- Wenn aktive mitgliedernummer = max(mitgliedernummer), status Mailing = 0 setzen

CRON-Job: alle 13 Sekunden den PHP-Mailer aufrufen, je nach schnelligkeit des mailservers kann das auch 60 sekunden oder 120 sekunden sein.

Mein Script hält sich selbst an, wenn das PHP-timeout erreicht wird: der gesetzte "*" ist dann da.
Man muss ein wenig rumprobieren, um die sinnvollste Kombination aus CRON-Intervall, anzahl E-Mail addressen aufs Mal und PHP-Timeout zu finden.
 
@PH
hättest du meinen 2. vorschlag genauer gelesen, wär dir aufgefallen, dass er ähnlich deinem arbeitet, nur mit dem vorteil, dass der cronjob das PHP Mailer Skript nur einmal aufrufen muss. Mit header ruft sich das Skript selbst auf, so beginnt der Skripttimeout von vorne.

Skripttimeout ist natürlich sinnvoll, aber man kann sie durchaus erhöhen, man muss nur das richtige mittelmaß für sich finden. Die Standardeinstellung ist mir zumindest zu niedrig.
 
naja, muss denn die browser-seite nicht göffnet bleiben, damit sich das script mit header selbst aufrufen kann?
 
Das kann ich nicht genau sagen, aber selbst wenn, wär das nicht unbedingt ein großes Problem. Die Timeouts werden ja nach dem header Aufruf immer zurückgesetzt. Man müsste das Browserfenster dann wieder schließen, entweder manuell oder per Code.
 
Zurück
Oben