On 12/14/11 20:28, Simon Hobson wrote:
Martin wrote:

when activating policyd in main.cf users which send a lot of mails
(newsletters) to our mailserver, have to wait a long time the mails
will send by her client (f.e. outlook).
Sometimes the client gives a timeout. The mails were send via BCC header.

Send few mails will be fast.
# telnet MAILSERVER 25 is very fast

Sending may 100 mails (100 recipients per BCC) will be slow (ca
5minutes to send with outlook).
200 mails round about 9 minutes
500 mails over 15 minutes
You can see our mail.log (delay)
You are exhibiting something not too dissimilar to what I've seen on my setup.

For performance testing, I copied a query from the verbose
cluebringer log, and then used a short bash script to squirt lots of
queries in using netcat. IIRC I could achieve a sustained rate of
something like 60 q/s without any problem.
Originally I had some errors in the postfix logs (using Postfix Admin) :
warning: mysql query failed: MySQL server has gone away
fatal:
mysql:/etc/postfix/sql/mysql_relay_domains_maps.cf(0,lock|fold_fix):
table lookup problem
These killed throughput, but went away when I upgraded the backend to
Debian Etch which includes upgrading MySQL from 5.0 to 5.1.

In the end, I determined that Postfix itself seems to throttle policy
server queries to about 2 per second for each process/thread. Thus if
I set my list server to use a single connection, it takes about
25s/message (it send emails to 50 recipients max/message) - but if I
use multiple connections and connect to multiple servers (I have a
little cluster of 3) then the rate scales linearly.

Since I got to a rate I was happy with then I didn't look any further.

I have the recipient limit set to 50 on my servers, we don't get many
complaints, and people are generally happy to use our Mailman server
if they want to run a mailing list. It makes it easier for them since
recipients can subscribe/unsubscribe themselves - so less admin
hassle.


I posted a patch to the ML a little while back which fixes pipelining of requests:
http://devlabs.linuxassist.net/projects/policyd/repository/diff?rev=0ad89343b16f4d53dca7ea695c61cef7ffb9d217&rev_to=8b1b6fae92a3a684162e5514e3c9c6d9f8374bc9

Unified diff at bottom right.

This should fix any 2 per second issues anyone had. If this was the cause of it that is :)

-N


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Users mailing list
[email protected]
http://lists.policyd.org/mailman/listinfo/users

Reply via email to