Extrem langsamer Mailversand

[prometheus]

hallo,

in einem forum hab ich rund 38000 user. wenn ich einen newsletter an alle versende geht das so langsam das selbst die 24 stunden grenze zur trennung der dsl leitung nicht ausreicht! das ganze ist jedenfalls extrem langsam. genutzt wird die einfache mail() funktion und es wird pro empfänger eine mail versendet (also nicht alle empfänger direkt im header als bcc z.b.)

php version 4.3.8
suse linux version 9.2

in der konfiguration hab ich nirgendwo etwas gefunden das der mailqueue nur ne bestimmte größe haben darf oder das nach ner bestimmten anzahl nen timeout kommt oder sonst was.

[dodolin]

Warum fuer eine solche Anzahl von Mails nicht eine dedizierte Mailinglisten-Software verwenden? Welcher MTA? Der Web-/Mailserver ist nur per DSL angebunden? Er hat also nur einen geringen Upstream? Er ist also auf diversen DUL's gelistet?

[Joe User]

Zuzüglich dodolins Fragen: Welche Forensoftware?

[prometheus]

ich glaub ich hab mich total falsch ausgedrückt ...

der server ist ein dedizierter root server von s4y und auch dementsprechend angebunden. das mit dem dsl war nur weil ich ja in der forensoftware im acp den mailversand starte und dort auch drin bleiben muss solange der mailversand geht (logisch bei mail per php).
forensoftware ist wbb 2.3.3
das blöde is die software unterstützt auch mailversand über ne smtp klasse in php aber das ist haar genau so langsam. deshalb denke ich hat php noch nicht mal sonderlich viel damit zu tun. ich tippe auf die einstellungen für den mailqueue aber ich hab noch keine einzige conf finden können wo da irgendwas drin steht.
mta ist sendmail version 8.12.10

in der phpinfo ist noch was drin von sendmail_path /usr/sbin/sendmail -t -i und könnten die optionen -t und -i damit zusammen hängen?

[dodolin]

Ich wuerde in den Maillogs anfangen zu analysieren. Du solltest sehen koennen, in welcher Frequenz die Mails von PHP reinkommen und auch in welcher Frequenz die Mails an die Empfaenger versendet werden. Das sollte dann schon eher Schluesse zulassen, wo die Engstelle sitzen koennte.

Oder meinst du, mit den bisherigen Angaben kann irgendjemand hier eine Aussage dazu machen?

[debianjunge]

ohne mich weit aus dem fenster lehnen zu wollen; ich vermute hier stark sendmail als bottleneck. installier doch mal ein Exim, lass es nicht als daemon laufen und erzähle deinem php via php.ini welches binary er zum versenden nutzen soll. trage dann noch ein splitt_spool in die mainconfig ein und teste das ganze dann noch einmal.

cheers,
rene

[dodolin]

installier doch mal ein Exim, lass es nicht als daemon laufen

Schlechte Idee. Wenn der nicht als Daemon laeuft hat die Queue schnell 38.000 Eintraege. Dass Exim nicht wirklich gut performt, wenn er eine grosse Queue hat (auch Split-Spool Config bringt da nur eine unwesentliche Verbesserung) ist weithin bekannt.

Sollte sich herausstellen, dass wirklich der Spool das Bootleneck ist, wuerde ich zu Postfix raten, der ein wesentlich besseres Spoolhandling als Exim hat.

Sollte es am Versenden liegen, koennte man ueber QMail nachdenken, auch wenn ich das nicht gerne sage. ;)

Nach wie vor tendiere ich dazu, zuerst mal zu analysieren und darauf basierend dann Empfehlungen zu geben, als unmotiviert grosse Teile des Systems einfach wahllos auszutauschen. YMMV.

[debianjunge]

Hi dodolin,

Schlechte Idee. Wenn der nicht als Daemon laeuft hat die Queue schnell 38.000 Eintraege. Dass Exim nicht wirklich gut performt, wenn er eine grosse Queue hat (auch Split-Spool Config bringt da nur eine unwesentliche Verbesserung) ist weithin bekannt.

hast du beweise/beispiele dafür ? mir wäre/ist das neu.

Nach wie vor tendiere ich dazu, zuerst mal zu analysieren und darauf basierend dann Empfehlungen zu geben, als unmotiviert grosse Teile des Systems einfach wahllos auszutauschen. YMMV.

sollte auch erstmal als quick&dirty test sein, um ein schnelles "jo, es geht auch schneller" zu bekommen

[legato]

Warum machst du es denn nicht als BCC?
Dann muss mail() nur einmal aufgerufen werden und dein MTA macht den Rest - der ist damit normalerweise "etwas" schneller als wenn mail() in einer Schleife aufgerufen wird, was ja bekanntlich ordentlich Ressourcen frisst.

Siche auch http://www.php-faq.de/q/q-mail-massenversand.html

[dodolin]

hast du beweise/beispiele dafür ? mir wäre/ist das neu.

Ich habe jetzt gerade keine Zeit, etwas konkretes rauszusuchen, aber auf exim-users wird das immer wieder mal regelmaessig erwaehnt.

Phil Hazel sagt auch selbst immer wieder, dass Exim fuer eine Umgebung designed wurde, wo > 90 % aller Mails sofort ausgeliefert werden koennen ("always on") und daher die Queue immer relativ klein ist.