Probleme beim Mailversand Postfix

E

Erfolg81

New Member
Hallo zusammen,

ich habe eine Webseite auf welcher ich unter anderem meinen Mitgliedern einen regelmäßigen Newsletter zusende. Der Versand erfolgt über die Webseite, entweder per sendmail oder smtp. Egal welche Versandoption gewählt wird, der Versand ist quälend langsam. Ein Newsletter an ca. 4500 Empfänger dauert etwa eine Stunde. Das wäre noch akzeptabel, wenn der Versand wenigstens vollständig erfolgen würde. Leider bricht der Versand des öfteren mittendrin ab, von Seiten des Script gibt es dann keine Möglichkeit der Versand an der Abbruchstelle wieder fortzusetzen.

Ich habe eine VServer mit Debian 5.0 Lenny und ISPCP Omega. Der Script der Seite läuft auf php. Während dem Mailversand scheint der Server nicht besonders ausgelastet, trotzdem läuft der Mailversand im Schneckentempo. Mir kommt es vor, als wenn irgendeine Limitierung greifen würde. So etwas hatte mein Hoster schon einmal aktiviert. Seit Monaten würde jetzt seiner Aussage nach aber keine Limitierung von dessen Seite mehr aktiv sein, behauptet zumindest er.

Wie kann ich testen, ob irgendwelche Limitierungen aktiv sind?
Wo können noch Engstellen sein, welche den Mailversand drosseln?

Gruß Marco
 
Bei jedem einzelnen Versand wird die Sendmail-Binary aufgerufen welches in die Queue schreibt, und und und. Der Versand ist, als Resultat, langsam.
Der folgende Blog-Post geht in die Details:
http://www.phpclasses.org/blog/package/9/post/2-The-Fastest-Ways-to-Deliver-Email-in-PHP.html

Eine generell verwendete Lösung ist PHPList in Kombination mit Cronjobs.
Da es timeout-resistent ist (es kann die Seite periodisch neu laden und den Versand weiterführen um Timeouts zu vermeiden) funktioniert es auch ohne Cronjobs.
Der Import von Emails ist recht einfach (genau wie Brücken zu bestehender Software) und man kann Double Opt-In sowie Opt-Out leicht realisieren.
 
d4f said:
Bei jedem einzelnen Versand wird die Sendmail-Binary aufgerufen welches in die Queue schreibt, und und und. Der Versand ist, als Resultat, langsam.
Der folgende Blog-Post geht in die Details:
http://www.phpclasses.org/blog/package/9/post/2-The-Fastest-Ways-to-Deliver-Email-in-PHP.html

Eine generell verwendete Lösung ist PHPList in Kombination mit Cronjobs.
Da es timeout-resistent ist (es kann die Seite periodisch neu laden und den Versand weiterführen um Timeouts zu vermeiden) funktioniert es auch ohne Cronjobs.
Der Import von Emails ist recht einfach (genau wie Brücken zu bestehender Software) und man kann Double Opt-In sowie Opt-Out leicht realisieren.
Click to expand...

Also es muss für meine Zwecke nicht unbedingt pfeilschnell sein. Ein anderer Webmaster versendet mit dem gleichen Script und sendmail 18000 Mails in 25 Minuten. Und das ohne große Optimierungsmethoden. Es muss also grundlegend irgendetwas nicht stimmen.

Anmerken kann ich noch, dass mein Servertraffic sich von Dezember mit 3GB auf Januar verdreifacht hat. Tendenz steigend. Seit einigen Tagen ist das Problem mit dem Mailversand akut, könnte also auch mit dem gestiegenen Traffic zu tun haben. Allerdings ist der Server anscheinend in keinster Weise ausgelastet?

Beim Mailversand erhalte ich neuerdings nach ca. 1000 Mails die Meldung im Browser:

"Fehler: Verbindung unterbrochen
Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde."

Die Seite selber reagiert relativ normal schnell, aber ab und zu gibt es Aussetzer mit kleineren Denkpausen von 3-5 Sekunden. Zudem ist mir aufgefallen, dass mein Server beim restart neuerdings ab und zu nicht neu startet.

Jemand eine Idee?
 
Was mir erst jetzt aufgefallen ist:
ch habe eine VServer mit Debian 5.0 Lenny und ISPCP Omega.
Click to expand...
Weder dein Betriebssystem noch dein Adminpanel werden noch mit kritischen Sicherheitspatches versorgt, im Fall des Betriebssystemes schon knapp 1 Jahr lang. In der Zwischenzeit gab es jede Menge sicherheitsrelevante Bugs und entsprechende Fixes für die Grundteile des LAMPP Stacks.

Während dem Mailversand scheint der Server nicht besonders ausgelastet, trotzdem läuft der Mailversand im Schneckentempo.
Click to expand...
Das kann an vielem liegen, u.a. den Festplatten Mountoptionen im Host oder paravirtualisierten Container, den Performance-Zuweisungen des Servers (ist ja "nur" ein vServer), usw...

Und das ohne große Optimierungsmethoden. Es muss also grundlegend irgendetwas nicht stimmen.
Click to expand...
Hat er überhaupt einen mit deinem Server vergleichbaren Dienst.
Es gibt mehr mögliche Bottlenecks als die üblichen Verdächtigen CPU und RAM. Netzwerk, Scheduling (sowohl IO als auch CPU), ... sind alles Faktoren welche eine grosse Rolle spielen zumal du dauernd zwischen PHP, der sendmail-Binary und dem Postfix Server herumhüpfst beim Versand.

Seit einigen Tagen ist das Problem mit dem Mailversand akut, könnte also auch mit dem gestiegenen Traffic zu tun haben.
Click to expand...
3GB Mail-Traffic?

Die Seite selber reagiert relativ normal schnell, aber ab und zu gibt es Aussetzer mit kleineren Denkpausen von 3-5 Sekunden.
Click to expand...
Klingt nach einem überladenen vServer respektiv oversold vServer Host. Falls es OpenVZ ist; was sagt die /proc/user_beancounters ?
Kann auch an anderen Faktoren wie zB der PHP-Einbindungsmethode liegen.

Beim Mailversand erhalte ich neuerdings nach ca. 1000 Mails die Meldung im Browser:
Click to expand...
APache respektiv, wahrscheinlicher, PHP hat einen Timeout erreicht und die Verbindung beendet. Deswegen die vorher genannte Empfehlung von PHPList.

Ich zitier auch mal aus der PHP Dokumentation:
It is worth noting that the mail() function is not suitable for larger volumes of email in a loop. This function opens and closes an SMTP socket for each email, which is not very efficient.
Click to expand...
 
Ich möchte mal noch einen anderen Aspekt hier einbringen. Warum wurde bisher noch nicht der Einsatz einer Mailing-Listen-Software wie z.B. mailman in Erwägung gezogen? Das würde vermutlich die meisten Probleme hier mit einem Schlag lösen.
 
Maillist-Programme schreiben aber List-*-Header ins Mail, das mögen normale Mailclients manchmal nicht und zeigen die Mails als Maillisten an.

Und manche Leute haben Zuhause Mailclients/Programme die mehr können als nur Mails versenden.

Mailman ist nur wirklich nicht brauchbar als Newsletterversand. Sorry.
 
Warum wurde bisher noch nicht der Einsatz einer Mailing-Listen-Software wie z.B. mailman in Erwägung gezogen?
Click to expand...
Ich hatte ja schon PHPList erwähnt welches Newsletterversand inklusive Ankoppeln an eigene Software ermöglicht.
 
d4f said:
Ich hatte ja schon PHPList erwähnt welches Newsletterversand inklusive Ankoppeln an eigene Software ermöglicht.
Click to expand...
Ooops, Asche auf mein Haupt, die Software kannte ich nicht.

GwenDragon said:
Maillist-Programme schreiben aber List-*-Header ins Mail, das mögen normale Mailclients manchmal nicht und zeigen die Mails als Maillisten an.

Und manche Leute haben Zuhause Mailclients/Programme die mehr können als nur Mails versenden.

Mailman ist nur wirklich nicht brauchbar als Newsletterversand. Sorry.
Click to expand...
Zu den Headern: diese entsprechen RFC 2369 - wie auch immer, das lässt sich problemlos in der Config deaktivieren. Insofern sehe ich das nicht als Knock-out-Argument. IMHO, lässt sich Mailman sowohl für die klassische Mail-Diskussion als auch für den Newsletter-Versand konfigurieren. (http://list.org/mailman-admin/node14.html)
 
Last edited by a moderator:
Wer konfigurieren will, kann ja Mailman nehmen. Ich habe nicht davon geredet, dass es ein NoGo ist.

Ich weiß ja nicht wie die Ansprüche an die Erstellung der Newsletter sind.
 
Was der Versand von Tausenden Mails anbelangt, muss ja niemand PHPs mail() in einer Schleife nehmen.
Ich würde in die Queue schreiben oder gleich die Mails über Socket versenden.
Aber das hängt davon ab, was die Erfolg81 so selbst programmieren kann.

Was Erfolg81 anbelangt, wird ja nur ein newsletter versandt, da finde ich eine größere Maillistensoftware overkill.
 
You must log in or register to reply here.
Back
Top